管理员文档 · 迁移与备份策略

变更前的记录

至少记录以下信息：运行环境、数据库类型、多服开关、limitations 文件名、world-wide 文件名、语言文件改动和玩家自定义 UI/领地数量。把这些信息与配置备份放在同一份维护记录里，便于定位策略变化。

推荐备份层次

1. 停服后备份整个 plugins/Dominion/，包括 SQLite 数据库、YAML、语言文件和导出目录；
2. 外部数据库执行数据库级备份，确认可以在另一套实例中读取；
3. 对服务端世界做独立备份；Dominion 的 export mca 只是一份受保护区块列表，不是世界备份；
4. 记录备份校验值或至少记录文件大小、时间与恢复测试结果。

插件升级

停服、备份、替换 JAR、启动、查看日志和普通账号测试组成最小闭环。插件生成新配置时，不要直接用旧 config.yml 覆盖。把需要的修改逐项迁移到新文件。对于 flags.yml 和 world-wide，要检查 flag schema 的变化。

数据库类型迁移

先用 /dominion export db 生成可追溯备份，再按照目标数据库配置和导入说明在测试服迁移。导入命令只用于迁移或恢复，不用于合并两个现有数据库。测试服应核对领地数量、世界、边界、父子关系、主人、成员、组、模板和传送点。

Residence 迁移

开启 residence-migration 后先执行单个 Residence 迁移，确认映射结果，再执行 migrate_all。迁移不是双向同步。在业务确认前不要删除 Residence 原数据。迁移完成后关闭开关，避免管理员重复执行迁移。

回滚原则

发生数据异常时先停服并保留现场日志，不要反复启动让插件继续写入。按“恢复插件目录和数据库 → 恢复对应世界 → 使用备份对应的插件文件启动 → 验证数据 → 再处理升级”的顺序回滚。任何手工修库都应在可复制的备份上进行，并留下操作记录。