数据备份恢复方案怎么选？从RPO/RTO到存储落地的实战思路

先想清楚：你要的是备份，还是能恢复

很多站长做备份的动作很统一：写个脚本，每天凌晨tar一份丢到另一块盘。真出事的时候才发现，备份文件是坏的、恢复要跑六个小时、数据库binlog根本没开。备份和恢复是两件事，备份是过程，恢复才是目的。

选方案之前，先把两个指标写下来：RPO（能丢多少数据）和RTO（多久能恢复）。业务能接受丢一天数据，和只能丢五分钟，方案成本差好几倍。这两个数字定不下来，后面选什么工具都是拍脑袋。

三种备份策略，别只选一种

全量备份恢复最快，但占空间、耗带宽；增量备份省资源，但恢复时要按链条回放，中间断一环就全废；差异备份介于两者之间。实际生产里更稳的做法是组合：每周一次全量，每天一次增量，重要库再叠加binlog或WAL持续归档。

• 数据库：物理备份打底，逻辑备份兜底，binlog单独异地存
• 静态文件：rsync增量同步 + 定期快照
• 配置文件：纳入Git或配置管理，别只躺在服务器上

还有一条常被忽略：备份要定期做恢复演练。没演练过的备份，约等于没有备份。建议每季度挑一个非核心环境，真实走一遍恢复流程，记录耗时，看看RTO是否达标。

存储放哪：本地、异地还是对象存储

本地盘做备份，防的是误删和程序bug，防不了机房级故障。真正要抗灾，至少要做到异地一份。海外业务常见的做法是：主服务器在本地区，备份推到另一地域的存储或服务器上，跨区域隔离风险。

如果主站在香港，可以考虑用一台香港大带宽服务器 X做备份节点，30M带宽跑夜间增量同步足够，同区域延迟低、恢复快。若业务对数据主权和跨区容灾要求更高，也可以把冷备推到其他地区的独立服务器上，用对象存储做归档层，成本更低。

选存储时关注三点：写入是否稳定、取回是否要额外费用、删除是否有保护期。有些低价方案取回流量贵得离谱，真到恢复那天账单比服务器还贵。

落地清单：五件事今天就做

• 确认RPO/RTO，写进文档，别只存在脑子里
• 数据库开启binlog或WAL归档，并异地保存
• 备份任务加失败告警，静默失败最致命
• 每季度做一次恢复演练，记录实际耗时
• 备份账号权限最小化，防止勒索软件一把梭

备份方案没有标准答案，只有匹配业务的答案。先把恢复目标定清楚，再倒推工具和存储，比一上来就比价格靠谱得多。