游戏服务器存档备份教程：自动备份与故障恢复实践

摘要

游戏服存档承载着几十甚至上百小时的游玩进度，一次损坏就可能让整个服务器的玩家失去积累。本文给出一套可落地的存档保护方案：区分存档损坏的几种成因、设计带热备份的自动化脚本、配置异地归档与保留策略、用恢复演练验证有效性，并给出版本更新和服务器迁移这两类高风险操作的处置流程。

一、先搞清存档是怎么丢的

不同成因对应不同的防护手段，只做一种备份往往覆盖不全。

这里有个关键推论：只保留最新一份备份是不够的。存档可能在几天前就已经损坏或被破坏，而你直到玩家反馈才发现，此时最新备份里存的也是已损坏的状态。多版本保留才是真正有用的。

另一个常被忽略的点：备份和存档在同一台服务器上时，实例被误删或磁盘损坏会让两者一起消失。异地归档不是可选项。

二、定位存档目录

不同游戏的存档位置差异很大，先确认准确路径。常见位置：

我的世界这里有个高频疏漏：主世界、下界、末地是三个独立目录，只备份 world 会丢掉另外两个维度的建筑。必须三个一起备份。

确认路径后先看一下体积，这决定备份策略：

du -sh /存档路径
du -sh /存档路径/*

存档体积通常在几百 MB 到几 GB 之间，据点建造规模大的世界会更大。体积决定了备份耗时和存储成本。

三、热备份还是停服备份

两种方式各有取舍。

停服备份：先停止游戏服务，复制文件，再启动。优点是文件状态一定完整一致。缺点是玩家会被中断连接。

热备份：服务运行中直接复制文件。优点是不影响玩家。风险是复制瞬间可能有数据正在写入，得到的文件可能不完整。

实践中的做法是以热备份为主，配合定期的停服备份：

• 高频的日常备份用热备份，不影响游玩。多数游戏的存档写入是周期性的，热备份拿到损坏文件的概率不高，而且有多版本可回退。
• 每日或每周做一次停服备份，选在玩家最少的时段，保证有一份绝对可靠的副本。

如果游戏支持存档落盘指令，热备份前先执行它，能显著降低拿到不完整文件的概率。多数游戏服务端提供了强制保存的管理命令，可以通过远程管理接口调用。

四、编写自动备份脚本

把上面的策略落到脚本里：

sudo nano /usr/local/bin/game-backup.sh

#!/bin/bash
set -euo pipefail

# ===== 配置区 =====
SAVE_DIR="/home/palworld/Steam/steamapps/common/PalServer/Pal/Saved/SaveGames"
BACKUP_DIR="/backup/game"
SERVICE="palworld"
KEEP_HOURLY=24      # 保留最近 24 份高频备份
KEEP_DAILY=14       # 保留 14 份每日备份
LOG="/var/log/game-backup.log"
# ==================

DATE=$(date +%Y%m%d-%H%M)
HOUR=$(date +%H)

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG"
}

mkdir -p "$BACKUP_DIR"/{hourly,daily}

log "备份开始"

# 存档目录存在性检查
if [ ! -d "$SAVE_DIR" ]; then
    log "错误：存档目录不存在 $SAVE_DIR"
    exit 1
fi

# 记录备份前的存档体积，用于异常判断
SIZE_BEFORE=$(du -sb "$SAVE_DIR" | cut -f1)
log "当前存档体积 ${SIZE_BEFORE} 字节"

# 执行备份
ARCHIVE="$BACKUP_DIR/hourly/save-$DATE.tar.gz"
if tar -czf "$ARCHIVE" -C "$(dirname "$SAVE_DIR")" "$(basename "$SAVE_DIR")" 2>>"$LOG"; then
    log "备份完成 $ARCHIVE"
else
    log "错误：打包失败"
    exit 1
fi

# 校验备份文件有效性
if [ ! -s "$ARCHIVE" ]; then
    log "错误：备份文件为空"
    rm -f "$ARCHIVE"
    exit 1
fi

if ! tar -tzf "$ARCHIVE" > /dev/null 2>&1; then
    log "错误：备份文件校验失败，可能已损坏"
    rm -f "$ARCHIVE"
    exit 1
fi

BACKUP_SIZE=$(stat -c%s "$ARCHIVE")
log "备份文件大小 ${BACKUP_SIZE} 字节，校验通过"

# 每日 04 点的那份额外保留为每日备份
if [ "$HOUR" = "04" ]; then
    cp "$ARCHIVE" "$BACKUP_DIR/daily/save-$DATE.tar.gz"
    log "已保留为每日备份"
fi

# 清理过期备份
cd "$BACKUP_DIR/hourly"
ls -t save-*.tar.gz 2>/dev/null | tail -n +$((KEEP_HOURLY + 1)) | xargs -r rm -f
cd "$BACKUP_DIR/daily"
ls -t save-*.tar.gz 2>/dev/null | tail -n +$((KEEP_DAILY + 1)) | xargs -r rm -f

log "备份结束"

脚本里有几处值得说明：

tar -tzf 校验这一步很关键。 它实际读取压缩包目录结构，能发现打包过程中断产生的损坏文件。不做这步校验，你可能积累了一堆打不开的备份而毫不知情。

空文件检查同样必要。 磁盘满、权限不足时，打包命令可能"成功"但生成空文件。

分层保留策略：高频备份应对短期失误，每日备份应对晚发现的问题。两者结合覆盖不同时间跨度。

记录存档体积：存档体积突然大幅缩小往往意味着出了问题（例如世界文件损坏或被清空），日志中的体积记录能帮助事后判断从哪一份恢复。

设置权限并加入定时任务：

sudo chmod 700 /usr/local/bin/game-backup.sh
sudo crontab -e

0 * * * * /usr/local/bin/game-backup.sh

每小时执行一次。频率可按存档变化速度调整——玩家活跃、进度变化快的服务器可以更频繁。

五、异地归档

本地备份完成后同步到对象存储，实现与服务器的物理隔离。

在脚本末尾追加同步步骤，使用对象存储提供的命令行工具或 S3 兼容接口上传。建议只同步每日备份，高频备份留在本地即可——这样既有异地保护，又能控制传输量和存储成本。

配置要点：

• 存储桶权限设为私有。 存档文件不需要公开访问。
• 使用子账号密钥并限定权限。 只授予该存储桶的写入权限，不要用主账号密钥。
• 配置生命周期规则，把较早的备份自动转为成本更低的存储类型，或在保留期满后自动删除。

六、恢复演练

没验证过的备份不算备份。 游戏服存档的恢复流程要在真正需要之前跑通一遍。

演练步骤

第一步，停止游戏服务：

sudo systemctl stop palworld

第二步，把当前存档移到一边而不是直接删除：

sudo mv "$SAVE_DIR" "${SAVE_DIR}.before-restore"

这一步很重要。 直接覆盖会让你失去回退的可能——如果恢复出来的存档有问题，当前状态也没了。

第三步，解开备份：

cd "$(dirname "$SAVE_DIR")"
sudo tar -xzf /backup/game/daily/save-20260910-0400.tar.gz

第四步，确认文件归属正确：

sudo chown -R palworld:palworld "$SAVE_DIR"

权限问题是恢复失败的常见原因。 用 root 解开的文件归属会是 root，游戏服务以专用账号运行时无法读写，表现为服务启动失败或存档加载不出来。

第五步，启动服务并验证：

sudo systemctl start palworld
sudo journalctl -u palworld -f --no-pager

验证清单：

• 服务正常启动，日志中无存档加载错误。
• 客户端能连入服务器。
• 角色数据存在，等级和物品正确。
• 建筑和据点完好。
• 世界地图状态符合该时间点。
• 记录整个恢复过程的耗时。

验证通过后，确认无误再删除之前移开的目录。

记录恢复耗时这一项容易被跳过，但很有价值。它告诉你真实故障时需要多长时间才能让玩家回来，也能反映流程是否需要简化。

把恢复步骤写成文档。真正需要恢复时通常是紧急情况，凭记忆操作容易出错，尤其是权限这一步。

七、高风险操作的处置流程

有两类操作最容易导致存档问题，处理方式需要专门说明。

游戏版本更新

客户端更新后服务端需要同步，而新版本可能改变存档格式，导致无法回退到旧版本。

流程：

1. 先手动执行一次备份，并确认备份文件校验通过。
2. 给实例创建一份快照。这是整机级别的保护，能同时覆盖服务端程序和存档。
3. 更新服务端。
4. 启动并验证存档能正常加载、玩家能连入。
5. 如果出现问题，优先用备份恢复存档；存档格式已不兼容时，用快照把整机回退到更新前状态。

关于快照的使用限制必须说清楚：轻量应用服务器在实例详情页的「快照」页签创建快照，通常 5 分钟内完成且无需关机。但回滚时，整块系统盘会恢复到快照时间点，快照之后的所有游玩进度都会被清除，运行中的实例会自动关机。所以回滚前一定要先把当前存档单独备份出来，或再打一份当前状态的快照。另外，每个地域的免费快照配额有上限，使用存储型套餐的实例不支持创建快照。

还有一点：销毁实例时该实例的所有快照会被同步删除。 把快照当作唯一保护手段，在实例被误删时会连快照一起失去。这正是异地归档不可省略的原因。

服务器迁移

换机器或升配时的流程：

1. 在原服务器上停服并做一次完整备份。
2. 把备份文件传输到新服务器。
3. 在新服务器上部署相同版本的服务端。
4. 恢复存档并修正文件归属。
5. 启动服务，验证存档完整。
6. 更新客户端连接地址或迁移域名解析。
7. 原服务器保留一段时间再释放，确认新环境稳定后再彻底下线。

第七步是留出的安全边界。新环境跑几天没问题再释放旧机器，比立刻释放更稳妥。

八、监控与日常维护

备份失败必须能被感知

这是最常见的盲区：备份任务默默失败了两周，直到需要恢复时才发现没有可用备份。

在脚本中加入通知逻辑：

notify() {
    curl -s -X POST "你的通知地址" -d "游戏服备份异常：$1" > /dev/null || true
}

在各个失败分支调用它。也可以配置外部检查，定期确认最新备份文件的时间戳在预期范围内。

日常检查清单

• 每周查看备份日志，确认执行成功且文件大小合理。
• 每周抽查一份备份，用 tar -tzf 验证可正常解开。
• 每月确认异地归档同步正常。
• 每季度做一次完整恢复演练。
• 关注存档体积增长趋势，异常波动要排查原因。
• 关注磁盘剩余空间，备份会持续占用。

内存与稳定性

部分游戏服务端存在长时间运行后内存占用持续上升的现象，最终可能被系统终止并造成写入中断。应对方式是配置定时重启，选在玩家最少的时段：

0 5 * * * /usr/bin/systemctl restart palworld

重启前提前通知玩家。如果内存长期贴顶，说明当前规格不足，需要考虑升配。

存档体积控制

存档会随游玩时间增长。如果体积增长过快导致备份耗时明显变长，可以考虑清理长期未登录玩家的数据（需提前公告并给出申诉渠道），或清理远离主要活动区域的无用建筑。这类操作前务必先备份。

九、玩家沟通与合规

建立预期

在服务器公告中说明备份策略：多久备份一次、能回退到什么时间点、遇到问题如何反馈。玩家知道有保护会更放心，也能在出问题时理解恢复会损失多少进度。

回退的沟通

恢复存档意味着回退到某个时间点，之后的进度会丢失。执行前告知玩家将回退到哪个时间点，让他们有心理准备。如果损失较大，考虑是否有折中方案。

权限管理

管理员权限要谨慎分配。误用管理指令是存档问题的常见来源之一。管理员密码要足够复杂且不与其他系统复用。

合规提醒

• 自建服务器与好友或社群联机属于正常使用。不要部署侵犯游戏版权的私服程序。
• 不要使用违反游戏用户协议的作弊工具或自动化脚本，这类行为存在账号封禁风险。
• 存档中可能包含玩家的角色名、登录记录等信息，属于个人信息范畴。备份文件要妥善保管，不要公开分享或用于其他用途。
• 如果服务器面向不特定玩家开放，需要对服务器内的内容和行为承担相应的管理责任。

备份体系建立起来之后，如果需要为多个游戏服建立统一的备份管理，或为服务器配置资源监控告警，可以作为下一步方向。

存档异地归档建议使用对象存储 COS，它提供高持久性、生命周期管理与按量计费；游戏服务器本身可使用轻量应用服务器，配合快照做整机保护，需要更大内存规格时可选择云服务器 CVM。