先算清楚你的 RPO 和 RTO，再谈方案

先算清楚你的 RPO 和 RTO，再谈方案

很多小团队上来就问"用哪个备份工具"，这是本末倒置。先回答两个问题：你最多能丢多久的数据？（RPO）恢复必须多快？（RTO）

一个做内部管理系统的小团队，数据库一天写入几千行，RPO 定在 1 小时完全够用，没必要搞实时复制。但如果你做的是电商交易，RPO 超过 5 分钟就可能直接亏钱。先拿张纸，把每个数据源（PostgreSQL、S3 文件、代码仓库）单独标一行，写上容忍度和恢复时长，后面所有决策都基于这张表。

3-2-1 原则的务实简化版

教科书说 3 份副本、2 种介质、1 份异地。小团队照搬会把自己搞死。我的建议是：

• 主库本地一份，保证日常读写性能
• 每天增量备份到对象存储（阿里云 OSS / AWS S3），用 rclone 或云厂商 SDK 都行，脚本里加一条 --checksum 防止传输损坏
• 每周做一次全量快照，单独放到另一个账号或另一个 Region，防止误操作删桶时连备份一起没

关键原则：备份目标和生产环境之间必须存在一道"隔离墙"，至少是不同 IAM 账号，最好是完全不同的云厂商。

备份脚本别写太聪明

小团队最大的翻车来源不是方案不好，是脚本太复杂没人看得懂，维护的人一走就烂掉。我的经验是：

• 备份脚本不超过 100 行，逻辑全部线性执行，不要封装超过两层函数
• 每一条命令后面检查退出码，失败直接走通知，不要"容错继续"
• 备份文件名带上时间戳和主机标识，格式固定如 db-prod-20250610T0300.dump.gz
• 上传后立刻做一次 gsutil ls 或 ossutil stat 确认远端文件存在且大小合理

跑通之后，把脚本扔进 cron 或 CI pipeline，不要依赖任何人在前端手动触发。

定期演练恢复，否则等于没备

这是小团队最容易跳过的一步。备份文件静静躺在 OSS 里，半年后真要恢复时发现：密钥过期了、压缩格式不认识、依赖的镜像版本拉不到了、恢复文档里写的步骤少了一半。

务实做法：在日历上设一个每月一次的定时任务，拉一台临时机器，走完完整恢复流程，记录耗时和卡点。如果 RTO 目标要求 2 小时恢复，演练必须实际跑在 2 小时以内才算达标。把这个过程写成一份不超过 30 行的 RECOVER.md，新人也能照做。

权限收紧：防自己比防黑客更重要

小团队翻车排名第一位：某人执行了错误的 SQL 或误删了存储桶。第二才轮到外部攻击。应对方法：

• 生产数据库账号只给 DML 权限，DDL 操作走审批，用 pt-online-schema-change 这类工具而非手动执行 ALTER
• 备份存储桶开启版本控制，并配置 Object Lock / WORM 策略，备份文件在保留期内不可删除不可覆盖
• 备份的上传密钥和恢复用的读取密钥分开，上传密钥权限最小化（只能 PUT 不能 DELETE），存到密钥管理服务里而不是写死在脚本

做到以上几条，小团队在资源有限的情况下，备份体系至少不会出现"备了但恢复不了"或者"备份被自己人删了"这种最致命的问题。