首先明确RPO(可接受的数据丢失量)与RTO(恢复时间目标),例如RPO为30分钟,RTO为10分钟。针对我的世界服务器,重点保护世界存档(world、region、level.dat)、插件数据(plugins 配置/数据库)和用户数据(playerdata)。在台湾服务器的网络与存储成本下,混合策略常见:本地增量备份+每日快照+异地完整备份。
建议:每10-30分钟做一次增量(或rsync增量),每日做一次完整压缩(tar+gzip或zip),每周导出数据库(MySQL/MariaDB或SQLite)。关键时间点可在低峰时段执行完整备份,保证不会影响玩家体验。
启用文件冻结或在备份前短暂锁服,确保level.dat一致性;为插件数据库配置一致性导出(mysqldump或sqlite3 .dump);使用加密传输(rsync over SSH)与存储加密(服务器端或对象存储加密)。
推荐使用rsync、restic、borg或rclone配合对象存储(如AWS S3、Google Cloud、或台湾本地对象存储)。restic和borg支持去重与加密,节省带宽与空间。用cron或systemd timer定时触发,配合小脚本完成世界文件冻结、快照、上传与过期策略。
1) 停止写入或切换服务器为只读模式(短暂停服或使用save-off/save-on命令序列);2) 执行rsync或打包world目录;3) 导出插件数据库;4) 使用restic/borg加密并上传到对象存储;5) 运行校验并清理过期快照。
脚本需限制权限(仅可读写备份目录);私钥使用ssh-agent或受限密钥;日志轮转与告警(备份失败邮件或Webhook);定期执行恢复演练以验证脚本有效性。
恢复前确认RTO要求和现可用资源:若主服务器损坏,准备备用主机或云实例(相同或更高配置),配置好防火墙与端口映射(默认25565)。确保备份仓库可访问并具备解密密钥。
1) 部署新服务器环境(Java版本、服务器Jar、插件);2) 从对象存储下载最近的完整备份并应用增量;3) 恢复数据库并更新配置,检查玩家UUID与权限;4) 启动服务器并开启写入;5) 立即做一次完整快照以形成新的恢复点。
使用预配置镜像(AMI/VM模版)可将部署时间缩短数分钟;将部分关键文件通过CDN或近源缓存加速下载;在台湾节点优先使用本地对象存储以降低延迟。
推荐至少在两个地理位置保存完整备份:台湾本地与邻近地区(如日本/香港),或者云端多区。可采用异地复制(object storage lifecycle replication)或按计划把备份同步到第二个区域,保证在整个台湾区域不可用时仍能恢复。
多活需要复杂的实时同步(延时、冲突处理),对Minecraft通常不实用。更常见是Active-Passive:主节点在台湾,备份节点在其他区域,发生故障时切换DNS或通过负载均衡指向备份节点并恢复最新备份。
制定DNS TTL策略(短TTL便于切换),准备自动化切换脚本,并定期演练災难切换,记录RTO与RPO是否满足预期。切换后进行完整一致性检查(世界完整性、插件功能、玩家数据)。
常见问题包括:备份文件损坏、备份链断裂、密钥丢失、数据库导出失败、备份占满磁盘。排查顺序:查看备份日志→校验备份哈希→尝试本地恢复一份测试副本→检查密钥与权限。
配置备份成功/失败告警(邮件/Slack/Webhook),监控磁盘使用率、任务运行时间与网络带宽。每月做一次完整恢复演练并保存演练报告,确保在实际灾难时团队能快速响应。
保持至少3份备份(本地、异地、长期归档),加密传输与静态加密,启用版本化与生命周期策略,定期更新备份脚本与依赖,记录恢复步骤并培训值班人员。