备份不算数，恢复演练才算：季度演练脚本
「有备份」和「能恢复」之间隔着一次演练。本文给出季度恢复演练的完整脚本（拉回、校验、真恢复、计时、归档五步）、RTO/RPO 的记录口径、以及演练发现的三类典型坏备份。
备份界最贵的一句话是「我们有备份」——最值钱的一句话是「上个月演练恢复用了 47 分钟」。没演练过的备份等于没有备份：压缩包缺文件、dump 被截断、异地密钥过期、恢复步骤只存在于离职同事的脑子里——这些坏法都只在演练里暴露。本篇是安全基线中心的演练实操篇：季度演练的完整脚本与记录口径。备份本身的搭建（3-2-1 与自动化）在面板与备份。
演练五步：完整脚本
# ── 准备：一台演练机（临时 VPS / 测试机均可，$5.34 档就够）──
# 第①步 · 拉回：从异地存储拉最近一份全量（验证异地链路与凭据仍然有效）
rsync -az backupuser@异地IP:/data/backup/主机名/ /restore/ && ls -lh /restore/
# 第②步 · 校验：归档完整性（不校验直接恢复 = 赌运气）
tar tzf /restore/site-最近日期.tar.gz > /dev/null && echo "tar 结构 ok"
gzip -t /restore/db-最近日期.sql.gz && echo "gzip 完整性 ok"
# 有校验和习惯的：sha256sum -c /restore/SHA256SUMS（备份时生成）
# 第③步 · 真恢复：解包 + 数据库导入到隔离环境（演练机就是隔离环境）
mkdir -p /restore/test && tar xzf /restore/site-*.tar.gz -C /restore/test
mysql -e "CREATE DATABASE restore_drill" && zcat /restore/db-*.sql.gz | mysql restore_drill
# 第④步 · 计时与断言：记录耗时，抽查关键数据在不在
time (echo "恢复计时以第①步起点算") # RTO 实测值
mysql restore_drill -e "SHOW TABLES;" | head # 关键表在
grep -r "关键业务标识词" /restore/test --include="*.conf" -l | head -3 # 关键文件在
# 第⑤步 · 归档：演练记录一页纸（模板见下节），演练数据删除
rm -rf /restore/test && echo "演练环境已清理"演练记录：一页纸模板
| 字段 | 本次填写 | 为什么记 |
|---|---|---|
| 日期 / 演练人 | ____ | 责任与节奏可见 |
| 备份集（哪一天的哪份） | ____ | 验证的是「最近的」不是「随手挑的」 |
| RTO 实测（拉回到可用） | ____ 分钟 | 这是你唯一可信的恢复时间承诺 |
| RPO 确认（数据截止到） | ____ | 对照业务可接受的数据丢失窗口 |
| 发现的问题与修复项 | ____ | 演练的全部价值在这一行 |
| 下次演练日期 | ____ | 季度节奏进日历，不进「有空再说」 |
记录归档纪律：演练记录与备份集分开存放（记录在文档库/仓库，备份在存储端）——灾难发生时，你需要在拿不到服务器的情況下找到「怎么恢复」的说明。
演练最常揪出的三类坏备份
- 坏法一：备份任务早就死了——crontab 还在，但磁盘满/凭据过期/路径变更后每次都在静默失败；发现方式：演练第①步拉回来的文件日期是三个月前。防御：备份脚本成功后 touch 一个心跳文件，监控拨测检查心跳时间戳——「备份成功的证据」和备份本身同样重要；
- 坏法二：备份不完整——tar 少了目录（SRC 变量没更新）、mysqldump 没带 --all-databases、配置文件在 /etc 而数据在 /var 只备了一个；发现方式：第③步真恢复后关键数据缺。防御：备份脚本里写「清单断言」（备份后 tar tzf 对照预期目录清单，缺了就报警）；
- 坏法三：恢复步骤失传——备份文件都在，但「先恢复哪个、数据库怎么导入、权限怎么修」没人记得；发现方式：第③步卡住开始翻聊天记录。防御：恢复步骤写成脚本（restore.sh）与备份脚本同库存放——恢复脚本也是备份的一部分。
频率与范围：季度演练的最小安排
- 季度全量演练：本篇五步全走，含异地拉回与真恢复——一年四次是「可信」的底线；
- 月度轻量抽查：只做①②（拉回 + 校验），10 分钟——验证链路与完整性，不验证恢复；
- 变更后即时演练：备份脚本改过、存储换过、机器迁移过——当周做一次五步全走，变更是坏备份的最大来源；
- 年度灾难桌面推演：不真恢复，走流程——「服务器全毁 + 异地存储一半不可用」的假设下谁做什么、先恢复哪个系统、对外通告什么——纸面推演暴露的是组织问题，脚本演练暴露的是技术问题，两类都要练。
演练的时间成本账：季度全量演练一次约 1–2 小时（含记录），月度抽查一次 10 分钟——全年投入不到两个工作日，换来的是「恢复时间从许愿变成实测数字」。这笔账在任何规模下都划算，因为它对冲的是唯一确定会发生的风险：备份总有一天要用，区别只在「那天你有没有演练过」。
与整体安全基线的关系
恢复能力是安全体系的最后一环也是唯一保证「一定用得上」的一环：防火墙与加固降低事故概率，备份与演练兜住事故后果——概率可以侥幸，后果不能。基线三件套的执行顺序：SSH 加固（第一小时）→ 防火墙基线（第一小时）→ 本篇（第一周建立、每季度验证）。
下一步：把下次演练日期写进今天的日历，把 restore.sh 写进今天的仓库。备份搭建与自动化红线在面板与备份；演练用的临时机器入门 VPS $5.34/月随开随删；全景回安全基线中心。