备份与恢复
为世界、配置和插件建立可验证的恢复能力，而不只是复制几个文件夹
备份的目标不是“多存一份文件”，而是在误删、更新失败、磁盘故障或插件事故后，能在可接受的时间内恢复服务。要做到这一点，备份必须完整、放在不同故障域，并且真的演练过恢复。
该备份什么
对于小型服务器，最简单可靠的做法是备份整个服务端目录。这样除了世界，还会带上插件、模组、配置、白名单、OP 名单和启动参数。只复制 world/ 往往不足以恢复一个能正常运行的服务器。
Paper 的世界与配置布局会随版本和世界命名变化；例如多世界、模组服和新版本维度数据不一定都使用 world_nether、world_the_end 这类固定目录名。整服备份可以避免遗漏这些差异。Paper 的配置目录说明可用于核对你的实际文件结构。
最稳妥的备份流程：停服后复制
- 在控制台执行
save-all，让服务端先请求保存。 - 执行
stop，等待进程完全退出。 - 将整个服务端目录压缩或复制到备份位置，并用日期命名，例如
2026-08-18-before-plugin-update。 - 确认文件大小合理、归档能打开，再记录本次备份对应的服务端版本和改动原因。
停服备份会有短暂维护窗口，但文件处于静止状态，最容易保证一致性。对第一次维护服务器的人来说，这是优先方案。
在线备份要满足什么条件
直接在运行时复制世界文件，可能把不同时间点的数据混在同一份备份中。save-all 可以改善这一点，但不能替代有一致性保证的备份方案。
如果必须在线备份，请使用明确说明支持你的服务端版本、能在备份前保存并在完成后恢复写入状态的工具或插件；先在测试副本上验证恢复流程。不要因为备份任务“没有报错”就假设它可用。
备份放在哪里
至少保留两份副本，其中一份不应位于服务端所在的同一块硬盘。常见组合是：本地归档 + 加密后的异地存储。上传到云盘前注意访问权限，因为配置、日志和玩家数据可能包含不适合公开的信息。
可以采用简单的保留策略：保留最近若干次日常备份，再额外保留每周或每次大更新前的版本。频率取决于你愿意承受多少数据回退：玩家活动越频繁，间隔就应越短。
恢复前先做三件事
- 停服并保留现场：把当前损坏目录改名，而不是立刻删除；它可能仍能帮助定位问题。
- 确认备份身份：核对备份日期、服务端版本、世界名称和插件/模组版本。
- 先在副本中启动：如条件允许，先把备份解压到另一个目录，确认日志和世界能正常加载，再替换生产目录。
恢复时通常应把整套目录还原，而不是只挑一个世界文件夹。若你只想回滚世界，也要确认当前插件和模组仍能读取该世界对应的数据格式。
每次备份都应验证
检查文件大小只是第一步。更可靠的验证是定期挑选一份备份，在隔离目录中启动一次，并确认世界、核心配置和玩家数据都存在。没有做过恢复演练的备份，只能算“可能可用”。