先定 RPO 和 RTO，再决定买什么

先定 RPO 和 RTO，再决定买什么

小团队最常见的失败模式是：买一台 NAS，把生产服务器 rsync 过去，就觉得备份已经做完了。三个月后机房断电，NAS 和生产机在同一个机柜、同一条市电、同一次事故里一起挂掉。备份方案不是从采购开始的，而是从两个数字开始的。

• RPO（能丢多少数据）：核心业务库建议压到 15 分钟以内，用 binlog 或 WAL 增量归档；内部文档、Wiki 这类 24 小时可以接受。
• RTO（多久能恢复）：给老板一个能兑现的数字。20GB 的 MySQL 全量恢复大概 20~40 分钟，1TB 的对象存储重新拉回来可能要几个小时，别拍脑袋承诺“半小时全部恢复”。

把这两条写进文档，后面所有的工具选型和预算都围着它们转。没有这两个数字，讨论“要不要上异地”永远没有结论。

数据库备份：一致性比频率重要

直接 cp -r /var/lib/mysql 是最典型的翻车操作，拷出来的文件大概率无法启动。要用逻辑备份工具，并且显式保证一致性：

• MySQL：mysqldump --single-transaction --quick --routines --triggers --events，InnoDB 表在事务里拿一致性快照，不会锁表；MyISAM 表另说，早点换掉。
• PostgreSQL：pg_dump -Fc 出自定义格式，恢复时可以用 pg_restore -j 4 并行，比纯 SQL 快好几倍。
• 备份脚本开头写 set -euo pipefail，末尾检查退出码和文件大小，空文件比没有文件更危险。

监控必须做“没消息就是坏消息”的反向告警：备份成功才去 ping 一下 healthchecks.io 之类的服务，超过预期时间没收到 ping 就打电话。靠脚本发邮件通知失败，最后一定被扔进垃圾箱。

3-2-1 在小团队的最小落地

3-2-1 指三份副本、两种介质、一份异地。小团队不需要三套硬件，可以这样配：

• 副本一：生产机本地磁盘，用于快速回滚。
• 副本二：办公室另一台机器或 NAS，通过 restic 或 borg 做去重加密备份，每天一次。
• 副本三：对象存储（阿里云 OSS、腾讯云 COS、Backblaze B2、Cloudflare R2），用 rclone sync 推上去。R2 出网流量免费，长期存放成本能省不少。

对象存储务必开版本控制和生命周期规则，例如 30 天转低频、180 天转归档。如果预算允许，再开对象锁（immutable）或桶的 append-only 策略，否则勒索软件拿到凭证后第一件事就是把你的备份删干净。保留策略建议 7 份日备、4 份周备、12 份月备，别无限堆积。

密钥和“备份的备份”

加密备份最讽刺的翻车场景：数据还在，密码没了。restic、borg 的仓库密码一旦丢失，备份就是一堆随机字节。

• 备份仓库密码存进 1Password、Bitwarden 这类密码管理器，并且不要存在备份服务器本身。
• 再打印一份纸质密码，放进保险柜或带锁的抽屉，这是唯一能对抗“密码管理器账号也丢了”的办法。
• GitHub 上的仓库用 gh repo clone --mirror 或 git bundle create 定期打包，别指望平台永远在。
• 顺带备份恢复码：域名注册商、云厂商主账号、SSL 证书私钥、2FA 的恢复码。这些东西丢了，数据恢复了业务也接不上。

不演练的备份等于没有备份

这一节最容易被跳过，但也是最值钱的。每季度在日历上固定一天做恢复演练，流程写死：

• 从异地副本拉一份最新的数据库备份，恢复到临时实例，绝不在生产机上原地恢复。
• 跑几条关键业务查询，确认表结构、索引、触发器都在，数据行数和预期对得上。
• 记录从零到可用的实际耗时，这个数字就是你的真实 RTO，写回文档，和当初的承诺对一遍。
• 演练完把发现的问题列成 checklist，下次演练逐条确认。

大多数团队第一次演练就会发现：备份任务其实两周前就静默失败了、恢复脚本里写死了旧的内网 IP、某个库根本没被纳入备份范围。这些问题在演练时暴露出来，成本是一下午；在真事故里暴露出来，成本是公司。