备份系统的工程问题可以归结为一句话：备份的价值 100% 体现在恢复上，而恢复那天行不行，取决于方案设计时有没有处理一致性、隔离性和可验证性。 本文按备什么、怎么备、放哪里、怎么验证的顺序展开，所有工具与机制均为公开存在的标准方案（pg_dump/mysqldump、rsync、LVM、binlog/WAL、rclone 等），不含虚构。
一、需求建模：RPO / RTO 先行
备份方案的所有参数都由两个约束推导：
- RPO（能丢多少数据）：决定备份频率与是否启用日志归档。RPO=1 天 → 每日全量导出；RPO=1 小时 → 数据库开启 binlog（MySQL）/ WAL 归档（PostgreSQL），定时 dump + 日志回放可恢复到任意时间点；
- RTO（能停多久）：决定是否需要备用机、整盘镜像或双机热备。
脱离这两个约束谈备份，通常演化为"每晚全量拷一遍"的伪方案------既不满足细粒度 RPO，也撑不住长期保留的存储成本。
二、备什么的完整清单
备份清单（三类）
├── 业务数据
│ ├── 数据库：pg_dump / mysqldump 逻辑导出（勿直接拷贝运行中数据目录）
│ └── 文件数据：图纸 / 附件 / 上传目录，逐目录登记
├── 配置
│ ├── /etc 下变更项（nginx、防火墙规则）
│ ├── crontab、systemd 自定义单元
│ ├── SSL 证书 + 私钥、SSH authorized_keys
│ └── 应用配置与环境变量（含密码的加密存储）
└── 运行环境
├── 代码版本、运行时版本、依赖清单
└── 容器编排文件（有容器化时）反清单同样要写：日志（留够时长即可）、缓存、临时文件不进备份------不加反清单的备份任务，最终多死于磁盘被垃圾数据撑爆后的静默失败。
为什么不能直接拷贝运行中的数据目录：数据库运行时数据文件持续变化，直接拷贝得到的是前后不一致的文件集，恢复时轻则报错重则无法启动。两个正解：官方工具逻辑导出（一致性好、速度慢），或先打一致性快照再从快照拷贝（速度快、依赖卷管理）。
三、怎么备：机制与坑
1. 全量 + 增量 + 阶梯保留。 每周全量、每日增量；保留策略按 7 天 / 4 周 / 12 个月三级阶梯。多版本保留的核心价值是防御"坏版本覆盖好版本"：误删发生后，下一次备份会把删除后的状态覆盖上去，单副本方案中该错误不可逆。
2. rsync 的两个行为必须吃透。 --link-dest 配合可实现"每日快照、重复文件硬链接不占空间"的快照池；而 --delete 是经典翻车点------线上误删后，带 --delete 的同步会把备份端的同名删除一并执行。同步是镜像不是备份：线上变成什么，同步端就变成什么，包括被加密。
3. 一致性快照。 LVM 快照对卷做写时复制（COW），打快照瞬间冻结一致视图，再从快照路径拷贝数据库文件，兼顾物理级速度与一致性。云盘快照同理，但注意边界（见第五节）。
4. 时间点恢复（PITR）。 开启 binlog/WAL 归档后，基础备份 + 日志回放可恢复到一天内任意时刻------"误删一张表想找回"场景的唯一救命机制，值得为它付出归档存储成本。
5. 整盘镜像（dd）作为低频底牌。 能在新盘原样复原整个系统，但慢、占空间、运行时镜像有一致性问题，适合维护窗口内每季度一次，不适合做日常主力。
四、3-2-1 与防勒索的权限模型
3-2-1 原则：3 份副本、2 种介质、1 份异地。小厂落地：本机另盘（防误删）→ 备用机/NAS（防单机故障）→ 异地服务器或对象存储，rclone 一条命令，月成本个位数。
防勒索的本质是权限单向化 + 物理隔离：
- 备份端对线上只增不删。 勒索软件拿到线上 root 后的第一动作是顺着已有连接加密/清空备份。对策：对象存储开版本控制、备份目录权限收紧、备份凭据不含删除权限------即使线上凭据全部泄露，备份也只可写不可毁；
- 离线副本。 每周全量拷至离线硬盘，拷完卸载锁柜。不联网、不挂载的介质是加密行为物理上够不到的终点。
自动化与告警：备份任务交给 crontab/systemd timer，但必须配三类告警------任务失败、产物体积低于阈值、连续 N 天无新产物。静默失败的备份任务是最危险的失效模式：任务"存在"给了所有人安全感，产物早已是空的。
一套典型任务清单：01:00 数据库导出 + 产物体积校验 + 异常通知；02:00 文件目录增量同步（只增不删）；03:00 推送异地对象存储（版本控制开启）；周五全量拷离线盘；每月测试库导入抽查；每季度另起机器完整恢复演练并记录耗时。
五、云快照的边界
云平台快照的三个边界必须写进方案：它与主机同账户（账户失守则快照同失）、同地域（区域级故障同失）、可被误操作停用。结论：云快照可作为 3-2-1 中的一层，不能作为唯一副本。
六、恢复演练：唯一有效的验证手段
备份体系的正确性无法靠检查备份文件验证（损坏、密码失传、版本错配、缺证书都看不出来），只能靠演练：
演练四步法
1. 低峰期，另起一台机器，用最新备份完整恢复
2. 真实启动：服务拉起、页面可达、登录成功
3. 数据抽查：最新业务记录存在且正确（恢复到三天前 = 技术成功、业务失败）
4. 记录端到端耗时 = 真实 RTO（出事时只多不少）首次演练的高频卡壳点：备份解压密码仅离职人员掌握；应用配置仍指向老机器地址；证书私钥从未备份；中间数日的备份任务早已静默失败。每个问题在演练中发现的成本是一下午，在事故中发现的代价是按天计的停机。 经验值：第三次演练做到两小时内从零到业务可用，备份体系才算达标。最终交付物是一页恢复手册：服务启动顺序、密钥存放位置、联系人------事故现场没人有时间翻长文档。
七、验证存量备份
已有大量历史备份文件时，不要去研究文件本身，直接演练：找台机器，拿最新一份恢复一次。演练通过率是备份体系唯一的成绩单。
灾备搭建属于典型的一次性交付项目：需求建模（RPO/RTO）→ 方案（清单/机制/存储布局/保留策略）→ 落地配置 → 完整恢复演练 → 交付恢复手册。我们摩杰斯在制造客户现场按这个流程交付过多年，核心业务系统本身也在 Linux 上跑了十四年------备份这件事的验收标准只有一条：恢复那天行不行。