恢复演练：只做备份不做恢复等于没有备份

备份任务显示 finished successfully，不代表这个文件能恢复出一台能开机的虚拟机。

真正出事的时候才第一次尝试恢复，是最糟糕的时机：你处在压力之下，没有试错空间，而且如果发现备份不可用，已经没有退路了。

恢复会覆盖数据

恢复到一个已存在的 VM ID，会清空并覆盖那台客户机的当前磁盘，不可撤销。

演练时务必恢复到一个新的、没被占用的 ID。本文全程使用新 ID。

演练要回答的三个问题

1. 备份文件能不能读出来？
2. 恢复出来的客户机能不能开机？
3. 开机之后，里面的数据是不是你以为的那个时间点？

第三个最容易被忽略，也最重要。

演练步骤

第一步：挑一台有代表性的客户机

选一台你真正在意的客户机来演练，不要挑那台什么都没装的测试机。备份和恢复的坑（guest agent、磁盘大小、直通设备）往往只在真实负载上才暴露。

第二步：在源客户机里留一个时间标记

这一步是为了回答问题 3。在源客户机内部执行：

# 在源客户机内部执行
date > /root/restore-drill-marker.txt
cat /root/restore-drill-marker.txt

记下这个时间。

第三步：跑一次备份

数据中心 → 备份 → 选中任务 → Run now，或者对单台客户机：客户机 → Backup → Backup now。

等任务完成，确认日志里是 finished successfully。

第四步：恢复到一个新 ID

客户机 → Backup，选中刚才那份备份，点 Restore。

字段	填什么
Storage	恢复后的磁盘放哪
VM ID	一个没被占用的新 ID，例如 999
Unique	勾上

Unique 这个勾一定要勾

勾上 Unique 会为恢复出来的客户机生成新的 MAC 地址。不勾的话，新旧两台机器 MAC 相同，同时开机会造成网络冲突——表现为两台机器的网络都时好时坏，非常难查。

不要在这一步开机

恢复完成后先别急着点 Start。下一步要先改网络。

第五步：避免和源客户机冲突

恢复出来的是源客户机的完整副本。直接开机会撞车：

冲突项	处理
IP 地址	源用静态 IP 的话，新机会抢同一个地址
主机名	日志和 DNS 会混乱
对外服务	两个实例同时连数据库、同时收任务

最安全的演练做法：给恢复出来的客户机换一个隔离的网络。

# 在宿主机执行：先看恢复出来的机器的网卡配置
qm config 999 | grep net

# 把它从 vmbr0 断开（临时办法：设置 link_down）
qm set 999 -net0 virtio=<保持原MAC>,bridge=vmbr0,link_down=1

link_down=1 相当于把网线拔了，虚拟机能开机但不联网。这样就不会和源机冲突。

更正规的做法是建一个隔离网桥

建一个没有上联物理口的 vmbr9，专门用来跑恢复演练和可疑的客户机。它们之间能通，但出不去。值得花十分钟建一个。

第六步：开机并验证

点 Start，然后 Console。

依次确认：

1. 能不能开机？ 出现登录提示符就算过。
2. 有没有文件系统错误？ 启动日志里有没有 fsck 修复的提示。有的话，说明备份时的一致性有问题——回头检查 guest agent。
3. 时间标记在不在？

# 在恢复出来的客户机内部执行
cat /root/restore-drill-marker.txt

内容应该和第二步记下的时间一致。这证明了恢复出来的是你以为的那个时间点的数据。

4. 服务能不能起来？ 如果这台机器跑着应用，确认应用的进程起来了、数据在。

第七步：清理

演练完成后删掉恢复出来的客户机：

# 确认 ID 没记错！
qm stop 999
qm destroy 999

destroy 不可撤销

qm destroy 会删除客户机配置和所有磁盘。执行前用 qm config <id> 再确认一次这是演练机而不是生产机。

三种真实场景的恢复

演练之外，实际会遇到的三种情况：

场景一：只丢了几个文件

不要恢复整台虚拟机。 那会覆盖掉其他还好的数据。

做法：恢复到一个新 ID，开机（断网），从里面把需要的文件拷出来，再删掉临时机器。

用 PBS 的话有更方便的方式——它支持直接浏览备份内容并提取单个文件，不需要恢复整机。

场景二：客户机崩了，要整机回滚

恢复到原 ID，覆盖当前状态。

覆盖之前先保留现场

如果磁盘空间允许，先把当前的坏状态也备份一份（或者打个快照）。理由：

1. 万一恢复出来的版本也有问题，你还能回到现在。
2. 事后排查「到底发生了什么」需要现场。

具体做法是先对当前状态跑一次 vzdump，标注清楚这是故障现场。

场景三：整台宿主机没了

这是最考验准备工作的场景。需要：

1. 装一台新的 PVE。
2. 接上备份存储（NFS / PBS）。
3. 从备份恢复所有客户机。
4. 恢复宿主机自己的配置：存储定义、网络、用户、防火墙规则。

第 4 步就是配置备份任务里提到的 /etc/pve 归档的价值所在。没有它，你要凭记忆重建所有配置。

这个场景也该演练

在虚拟机里装一台 PVE，接上你的备份存储，试着恢复一台客户机。这能验证「备份存储在新机器上能不能访问」——这一点在真出事时经常卡住（NFS 权限、PBS 的加密密钥丢了、凭据记不清）。

恢复演练该多久做一次

• 备份方案刚配好时：立刻做一次。
• 改动了备份配置、存储、或 PVE 大版本升级后：做一次。
• 平时：每季度一次，或至少每半年一次。

把它写进日历

恢复演练是典型的「重要但不紧急」的事，不设提醒就永远不会做。在日历上设一个每季度的重复事件。

检查结果

一次合格的演练，你应该能回答：

1. 从备份到恢复完成，花了多长时间？（这就是你的恢复时间目标 RTO 的实测值）
2. 恢复出来的数据是哪个时间点的？和你的预期差多少？（这是恢复点目标 RPO）
3. 过程中有没有卡住的地方？（凭据、权限、网络冲突、空间不足）
4. 如果这是真的故障，这个时间和数据损失你能接受吗？

第 4 个答案是 No 的话，说明备份频率或方案需要调整。这正是演练的价值——在没有损失的情况下发现问题。

延伸阅读

• 配置备份任务与保留策略
• 快照、克隆与模板
• 迁移与救援