下午三点，机房 UPS 起火，整排机柜断电。

领导站在你身后问了一句：“数据能恢复到几点？”

你心里一算：备份是每天凌晨两点跑的。也就是说，凌晨两点到下午三点这 13 个小时的订单、注册、改动——没了。

更扎心的是下一句：“那备份放在哪？”就放在同一个机房的那台备份服务器上。

“我们每天都做全量备份，没问题的。”这句话藏着两个漏洞：一是“每天一次”，最坏意味着丢掉接近 24 小时的数据；二是就算数据完好，把服务重新跑起来，可能还要几个小时甚至几天。

备份和容灾，从来不是一回事。这篇讲清楚两者的区别，以及衡量它们的两把尺子——RPO 和 RTO。

一、先破一个误区：备份 ≠ 容灾

备份（Backup）解决的是：数据丢了、坏了、被删了，能不能找回某个时间点的版本。

容灾（Disaster Recovery）解决的是一个大得多的问题：整个机房没了，服务能不能尽快重新跑起来。这不只涉及数据，还有计算资源、网络、应用部署、域名切换，以及“谁来拍板切换”。

只有备份、没有容灾，数据安安静静躺在某块盘里，却没有现成的服务器和网络把它“用起来”。临时申请机器、装环境、导数据、调配置，每一步都在灾后现场摸索。

反过来，只有容灾、没有备份，同样危险，后面单独说。

二、两把尺子：RPO 和 RTO

RPO（Recovery Point Objective，恢复点目标）：灾难发生后，你最多能接受丢多长时间的数据。

每天凌晨两点做一次全量备份，RPO 的理论上限就接近 24 小时：灾难恰好发生在下一次备份之前，上次备份之后的新数据全部丢失。

有三个细节容易被忽略：

• 恢复出来的数据，停在备份的一致性时间点，不是备份“跑完”的时间。比如 mysqldump --single-transaction 拿到的是导出开始那一刻的数据。
• 如果最近一份备份恰好是坏的，你只能退回前一天，RPO 直接变成 48 小时。
• 如果备份和生产在同一个机房，机房一烧，备份一起没了，RPO 就不是一天，而是“全部”。

RTO（Recovery Time Objective，恢复时间目标）：灾难发生后，你最多能接受花多长时间让服务恢复。

RTO 不只是“导数据要多久”，而是从发现故障、决定切换、准备机器、恢复数据、回放日志、验证，到切流量的全过程。

算一笔账（假设恢复吞吐 200 MB/s）：2 TB 的备份，光是拷回来就要 2,000,000 MB ÷ 200 MB/s ≈ 10,000 秒，接近 3 小时，还没算解压、导入和建索引。

另外，RPO/RTO 是目标，不是你实际能做到的值。实际能做到多少，只有演练过才知道。

三、想把 RPO 从“一天”压到“几分钟”：靠日志，不是靠更多全量

每小时做一次全量？对大库来说既慢又贵。数据库更常用的办法是：全量备份 + 持续归档日志，做时间点恢复（PITR）。

• MySQL：先恢复全量备份，再用 mysqlbinlog 从备份记录的 binlog 位置开始，回放到故障（或误删）之前的那一刻。MySQL 8.0 默认开启 binlog。
• PostgreSQL：pg_basebackup 做基础备份，配合 archive_mode=on 持续归档 WAL；恢复时设置 restore_command 和 recovery_target_time，再放一个 recovery.signal 文件（PG 12 起）。

但注意两个前提：

1. 日志必须及时离开这台机器。 binlog/WAL 如果只存在本机，机房烧了照样没用。MySQL 可以用 mysqlbinlog --read-from-remote-server --raw --stop-never 把 binlog 实时拉到另一台机器；PostgreSQL 可以用 pg_receivewal 流式接收。
2. 这条链路是异步的。 RPO 约等于“还没传出去的那一段”：WAL 默认按 16 MB 段归档，写入少时一段可能很久才写满，可以用 archive_timeout 限制最长间隔。所以它能把 RPO 压到秒级或分钟级，但不是零。

顺便说一下增量和差异备份，这两个经常被说反：

它们本身不降低 RPO，降低 RPO 靠的是备份更频繁；增量和差异的价值，是让频繁备份更便宜。

四、三个“看起来像备份，其实不是”的东西

1. RAID 不是备份。 RAID 只防一件事：坏盘。rm -rf、误执行的 DROP TABLE、勒索加密，RAID 会“忠实地”写到每一块盘上；阵列卡故障、机房起火，它更无能为力。

2. 快照不一定是备份，要看它存在哪。 LVM、ZFS、存储阵列的快照，和原数据在同一个池、同一批盘上，底层存储坏了或机房没了，快照一起消失。云硬盘快照存放在独立于云盘的存储上，比本地快照可靠得多，但通常仍在同一个地域、同一个账号下，账号被盗一样能被删掉。另外，对数据库直接打的快照一般只是“崩溃一致”，相当于拔电源后的状态，要靠数据库自己的崩溃恢复，最好先确认能正常启动。

3. 主从、热备、双活也不是备份。 这就是“只有容灾、没有备份”的风险：同步越实时，误删和勒索加密也同步得越快。主库上一条没带 WHERE 的 DELETE，一秒后从库、同城、异地全部“整齐划一”。这时 RPO 取决于你最后一份没被污染的备份。

补救手段之一是延迟从库，例如 MySQL 8.0.23 起的 CHANGE REPLICATION SOURCE TO SOURCE_DELAY=3600，让一台从库永远晚一小时，给你留一个反悔窗口。但它只是缓冲，不能替代真正的备份。

五、备份怎么放才算安全：3-2-1 原则

• 3：至少 3 份数据（生产数据本身算 1 份）；
• 2：放在至少 2 种不同的存储介质或系统上；
• 1：至少 1 份在异地。

现在常见的加强版是 3-2-1-1-0：再加 1 份离线或不可变的副本（比如开启 Object Lock 的对象存储、断开连接的磁带或硬盘），防的是拿到你服务器权限、顺手把备份也删了的勒索团伙；“0”指恢复校验零错误——备份能恢复，才算备份。

回到开头那个机房：如果备份每天传一份到异地对象存储，再配上实时外传的 binlog，那天下午的损失可能只有几分钟，而不是 13 小时，更不是“全部”。

六、常见的容灾模式

注意：热备是“一边干活、一边等着”，双活是“两边都在干活”，两者经常被混为一谈。另外，表里所有 RPO 都只针对“机房没了”这类故障；对误删和勒索，它们统统要回退到上一节的备份。

国内常说的两地三中心，就是把这几层叠起来：同城两个中心（距离近，可以做同步复制或双活，应对单机房故障），加一个异地中心（通常是异步复制，应对城市级灾难）。上云之后，跨可用区、跨地域的能力是现成的，但云平台不会替你设计架构——只是把服务器“搬上云”，不等于有了容灾。

七、没演练过的方案，等于没有方案

很多公司有一份漂亮的容灾文档，却从没真正恢复过一次。问题往往只在演练时暴露：备份文件悄悄坏了几个月；手册里某条命令写错了；会操作的人恰好联系不上。

一份最小的恢复演练清单（以 MySQL 为例，务必在隔离的测试机上做，不要连生产库）：

# 1. 确认备份真的在产生，而且异地也有一份
ls -lh /backup/mysql/ | tail -3

# 2. 校验完整性（备份时同时生成 sha256）
sha256sum -c /backup/mysql/full-20261014.sql.gz.sha256

# 3. 在测试机上恢复全量，并计时（这就是你 RTO 的一部分）
time (gunzip -c full-20261014.sql.gz | mysql -uroot -p)

# 4. 从备份记录的位置回放 binlog，停在故障时刻之前
#    起始位置（157 为示例）见 dump 文件头部的 CHANGE REPLICATION SOURCE / CHANGE MASTER 注释
#    （导出时需加 --source-data=2，8.0.26 之前叫 --master-data=2）
#    注意：--start-position 只对第一个 binlog 文件生效
mysqlbinlog --start-position=157 --stop-datetime="2026-10-14 14:59:00" \
  binlog.000123 binlog.000124 | mysql -uroot -p

# 5. 抽查关键表的行数和最新记录，确认数据停在预期时间点
mysql -uroot -p -e "SELECT COUNT(*), MAX(created_at) FROM shop.orders;"

跑完记下两个数：实际恢复到了几点（真实 RPO），全程用了多久（真实 RTO）。和文档里写的目标一对比，差距一目了然。

写在最后

“我们每天都做全量备份”之所以危险，是因为它让人以为问题已经解决了。备份只回答了“数据能不能找回来”，没回答“能找回到几点”“备份会不会一起没”；容灾要回答的，是“整套服务能不能在可接受的时间里重新跑起来”。

RPO 和 RTO 也不是越低越好：核心交易系统可能要求 RPO 接近零、RTO 按分钟算，内部报表系统丢一天、停半天也能接受。投入要和业务的真实容忍度匹配，答案最终得靠演练验证。

你们公司的备份放在哪？上一次真正恢复演练是什么时候？欢迎在评论区聊聊，也欢迎指出文中不准确的地方，我会整理改正。

阅读原文：原文链接