备份与恢复操作手册

备份与恢复操作手册：每天备份，更要每月恢复

备份这件事有个残酷的真相：备份的“完成”不代表“可用”。很多站点的备份脚本天天跑、日志天天刷，真到需要恢复的那天，才发现备份文件是坏的、缺的，或者根本没有异地的副本。所以这本操作手册的核心只有一条：备份的频率由业务承受力决定，而恢复演练的频率决定备份的可靠性。

备份策略总览

增量备份的恢复依赖“全量+增量”链条的完整，所以除了每日全量，还要在每月演练时验证“从最近一次全量加全部增量”能否恢复出最新数据。保留周期也不是越长越好：30 天的保留应对“误删、事故”这类需求足够，更早的数据通常价值很低，却会持续消耗存储和演练成本。

数据库备份怎么做

以 MySQL 为例，全量备份 + binlog 增量是常见组合：

# 每日 03:00 全量备份
mysqldump --single-transaction --routines --triggers \
  -u backup -p$DB_PASSWORD yourdb \
  | gzip > /backup/mysql/db_$(date +%F).sql.gz

# 开启 binlog，作为增量备份
mysql -e "SET GLOBAL log_bin=ON;"

# 保留 30 天，超过自动清理
find /backup/mysql -name "*.sql.gz" -mtime +30 -delete

PostgreSQL 用 pg_dump -Fc（自定义格式）配合 WAL 归档，思路相同。

异地与 3-2-1 规则

再强调一遍 3-2-1 原则：3 份数据副本，存储在 2 种不同介质，其中 1 份放在异地。服务器本身不是备份——磁盘损坏、机房故障、勒索软件，都可能让“同一台机器上的备份”一起消失。至少把一份备份同步到对象存储或另一台机器：

# 用 rclone 把备份同步到对象存储
rclone copy /backup/mysql b2:bucket-16idc/mysql --transfers 8

同步之前记得先加密：对象存储本身不能替你保守秘密，谁拿到访问密钥都能读。推荐在本地用 gpg --symmetric 或 age 加密后再上传，密钥单独保存。恢复演练时也要演练“解密 + 恢复”的完整链路，只验证到“能下载”是不够的。

每月恢复演练的标准流程

1. 在干净环境（新服务器/容器）里搭建与生产一致的环境
2. 从最近的备份恢复到某个时间点
3. 校验数据一致性：行数、关键表校验、最新一条记录的时间
4. 记录三项指标：恢复耗时、数据是否一致、演练中发现的问题
5. 把问题写进改进清单，下次演练前修复

演练记录建议用固定格式沉淀，例如：

备份方案选型：全量、增量还是差异

选择时先回答一个问题：业务能接受多长的恢复时间（RTO）？恢复时间目标直接决定了备份方案——如果要求 30 分钟内恢复，那么靠“全量 + 最近一次差异”比“全量 + 一串增量”更稳妥，因为要重放的备份文件更少。

对于中小站点，我的建议是从“每日全量 + 每小时增量”起步，配合每月恢复演练。数据量大了之后，再评估是否需要引入差异备份或快照方案，不要一开始就上复杂的备份架构。

给备份加监控：备份脚本本身也要被监控。建议让备份脚本在成功/失败时都发通知，失败时自动重试一次并告警，避免“备份一直失败但没人知道”的静默失效。

常见问题

• 备份能跑但恢复不出来：原因多为没加 --single-transaction 导致备份期间数据不一致，或压缩包损坏。恢复演练就是为此设计的。
• 磁盘被写满：备份脚本没有清理策略，把系统盘塞满，反而导致服务故障。务必加 -mtime 清理和磁盘告警。
• 加密密钥丢失：备份加密后密钥只有一份，丢了等于没备份。密钥要另存，并纳入密钥管理。
• 只备份了数据库忘了文件：很多站点的用户上传、静态资源也存在服务器上，只恢复数据库会得到半个站点。备份策略要把“数据库 + 文件资产 + 配置”一起纳入。

参考：MySQL mysqldump 文档 https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html
参考：PostgreSQL 备份与恢复 https://www.postgresql.org/docs/current/backup.html
参考：Veeam 关于 3-2-1 备份规则的介绍 https://www.veeam.com/blog/backup-rule-3-2-1.html