Java 版开服教程维护与备份
日常维护清单
把“等出问题再修”改成可重复的例行检查，减少意外停服和不可追溯改动
小型服务器不需要复杂的企业监控系统，但需要一个稳定的维护节奏。最实用的方法是把检查拆成短小的日常、每周和变更前任务，并且每次只记录真正影响服务的结果。
每次启动后
启动成功不等于服务可用。管理员至少应检查以下几项：
logs/latest.log中没有明显的插件、模组、端口或 Java 报错。- 使用普通权限测试账号进入服务器，确认登录、出生、聊天和核心玩法可用。
- 控制台没有持续重复输出同一种警告或异常。
- 如果刚改过网络、域名或资源包，使用局域网外的网络再测试一次。
把“第一次红色日志”保留下来比盯着最后一行更有价值。遇到问题时，参照日志与故障定位收集完整证据。
每周维护
| 检查对象 | 要看什么 | 处理原则 |
|---|---|---|
| 备份 | 最近备份是否存在、大小是否合理、能否打开 | 定期在隔离目录做一次恢复演练。 |
| 磁盘空间 | 世界、日志、备份是否持续增长 | 不要等磁盘满了才清理；先确认哪些文件可安全归档。 |
| 更新 | Paper、关键插件和模组的发行说明 | 先测试，再安排维护窗口；不要在高峰期直接替换。 |
| 权限与成员 | OP、白名单、面板账号是否仍有必要 | 按最小权限原则移除过期访问。 |
| 性能 | 是否出现玩家可复现的卡顿 | 有问题再抓 spark 报告，不凭感觉乱调参数。 |
Paper 的更新文档强调，更新时需要备份世界、服务端配置、插件配置和插件 jar；插件可以放入 plugins/update/ 后在重启时更新。这项机制应先在测试环境确认你安装的插件兼容后再用。1
每次变更前
所谓变更包括更新 jar、加插件、换模组、调整权限、改网络、替换资源包或修改世界数据。每次变更前都应完成：
- 记录当前版本和计划目标。
- 备份整个服务端目录，标记日期和变更原因。
- 将变更拆小；一次不要同时升级 Minecraft、Java、十个插件和网络配置。
- 准备回滚路径：旧 jar 在哪里、旧配置怎么恢复、谁负责验证。
- 维护结束后记录结果和未解决事项。
不需要做的“维护”
不要为了看起来勤快而每天重启、每天清掉所有掉落物、每天强制更新插件。没有明确问题或计划时，这些操作只会增加中断和数据不一致的机会。维护的核心是可预测和可恢复，而不是操作次数。