一、先把 RPO / RTO 写成具体数字

一、先把 RPO / RTO 写成具体数字

备份方案不是越贵越好，关键是先回答两个问题：能接受丢多少数据（RPO）、能接受停多久（RTO）。小团队定一个够用的基线就行：核心业务库 RPO 15 分钟、RTO 2 小时；用户上传的文件和图片 RPO 24 小时、RTO 8 小时；日志、埋点这类可以接受丢一天。把这三个数字和对应负责人写进仓库根目录的 RUNBOOK.md，而不是留在某个人脑子里，因为那个人休假时最容易出事。

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

原则是三份副本、两种介质、一份异地。具体做法是：生产机本地快照（LVM/ZFS 或云盘快照）、同城另一台机器、对象存储。对象存储务必开版本控制和生命周期规则，条件允许再开 Object Lock，防止勒索软件把备份一起加密删掉。

• 数据库用 pg_dump -Fc 每天全量，配合 WAL 归档做 PITR；MySQL 用 mysqldump --single-transaction 或 xtrabackup。
• 文件用 restic 增量推到 S3 兼容存储：restic -r s3:... backup /data --exclude-caches，自带加密和去重。
• 别忘了“配置”：.env、Nginx 配置、crontab、CI 变量、DNS 记录、第三方账号的恢复码。只备份数据库的人，重建时一定会在配置上卡两天。

三、让备份可验证、可告警

最常见的翻车不是没备份，是备份了但恢复不了。三件事必须做：

• 校验：备份完算 sha256 写进清单；restic 定期跑 restic check --read-data-subset=5%。
• 自动恢复演练：每周把最新备份 restore 到一台临时库，跑几条 select count(*) 和主库比对，不一致就告警。
• 监控：任务失败告警之外，重点盯“最新备份时间戳超过阈值”和“备份体积突降 50%”。后者能抓住 pg_dump 中途报错但仍返回 0 的经典坑。

四、几个真实踩过的坑

• 备份脚本跑在被备份的那台机器上，机器挂了脚本也没了。调度要放到外部（云函数、另一台机器、CI 定时任务）。
• 磁盘写满，dump 写了一半，文件存在但不可用。备份前先检查剩余空间，写入用 .tmp 后缀，成功后再 mv 成正式文件名。
• 密钥和备份放在同一个桶里，等于没加密。
• 只有一个人会恢复。至少让两个人各自独立做过一次完整恢复演练，并把耗时记进 RUNBOOK。