备份做了却不敢恢复？聊聊数据备份恢复方案怎么选

2026-09-23 18:42 1007 次浏览

数据还在，业务却停了——这种情况我见过不少。服务器硬盘没坏，机房也没出事，问题出在没人敢点那个恢复按钮。因为谁也不知道备份里到底有没有东西，上一次成功恢复是什么时候，恢复要跑几个小时。真到要用的那天，才发现备份文件是空的、快照是坏的、数据库 binlog 少了最后两小时。

备份和恢复是两件事。备份是往兜里装钱，恢复是掏出来能不能花。多数方案只解决了前者。这篇想聊的是，怎么在花钱之前就把「能不能恢复」这件事定下来，别等到出事才补课。

先定 RTO 和 RPO，再谈买什么

两个指标定不下来，选什么方案都是拍脑袋。RPO 是你能接受丢多少数据，RTO 是从出事到业务重新可用能忍多久。这两个数字直接决定预算量级。

能忍丢一天数据、停一天业务，本地加一块硬盘做每日全量就够，成本几乎为零。只能丢 5 分钟、停 30 分钟，那得上实时同步加自动切换，预算翻十倍不止。

我一般会先问一句：如果现在数据全没了，业务能撑几天？答案通常比老板嘴上说的宽松。多数中小业务真实可接受的 RPO 在 1~4 小时，RTO 在 2~8 小时，这个区间用「定时快照 + 异地增量」就能覆盖，不必上双活。

只做一层备份等于没做，这是踩过坑之后的结论。三层指的是本地、异地、离线。

第二层最容易被省掉，理由是「机房很稳」。机房稳不稳和你会不会误删是两回事。rm -rf 一条命令下去，本地快照跟着一起删的情况太常见了。

离线层可以不做每日，一周一次甚至一月一次都行，但必须有。勒索软件加密在线备份是标准动作，2026年这类事件没少过。

这是整篇里我最想强调的一段。备份成功率和恢复成功率是两码事，中间隔着数据库版本、字符集、依赖服务、配置文件这些细节。

我见过不少这样的配置：备份脚本跑了两年，日志全绿，真恢复时发现 mysqldump 没加 --single-transaction，导出来的是不一致的数据。或者快照是文件级的，恢复出来数据库直接起不来。

演练要做的几件事：

演练最大的成本是人力，一次大概半天。相比真出事时停一整天，这半天很便宜。换我我会把演练排进季度计划，和发版一样当成固定动作。

数据量小的时候，托管方案划算。1TB 以内、RPO 容忍 1 小时以上，用云厂商的对象存储加定时脚本，月成本大致几十到一百多块，省心。

数据量上到几 TB 或者对恢复速度有要求，自建物理机更划算。一台美国西雅图站群 XI，E3-1230 配 16G 内存、100M 带宽，月付 $139，拿来做备份中转和恢复演练环境绰绰有余。100M 带宽意味着每小时能传大约 45GB，1TB 数据追平大概 22 小时，做夜间增量完全够。

数据量再大、要跨地域容灾的，可以考虑西雅图裸机云服务器 III，E5-2680 加 32G 内存、100M 带宽，月付 $99，适合当异地备份节点。注意是异地——备份节点和生产机房不在同一个地域，否则一场区域性故障两层一起倒。

不选云主机/VPS 做备份主力的原因很直接：磁盘 IO 和带宽是共享的，恢复大文件时速度波动大，RTO 不好估。备份这件事最怕的就是关键时刻速度不可控。

几十 GB 级的数据，本地快照加对象存储冷备，月成本控制在百元内，RPO 定 4 小时，够用。

几百 GB 到几 TB，本地快照加一台异地物理机做增量，月成本一两百美元，RPO 能压到 1 小时以内。上面那台 $139 的西雅图配置就是这一档的典型选择。

对恢复时间有硬要求、数据又上到十几 TB 的，再考虑双活和专线，那已经是另一个预算量级。多数业务走不到这一步，先别为它付钱。