3.13 Linux 备份策略与灾难恢复方案

预计阅读时间：18 分钟

学习目标

学完本章后，你将能够：

• 理解 3-2-1 备份原则及其背后的安全设计思想
• 使用 rsync 和 tar 备份文件系统
• 使用 mysqldump/pg_dump 备份数据库
• 编写自动化备份脚本并设置定时任务
• 建立备份验证和灾难恢复流程

核心知识

• 3-2-1 备份原则——3 份数据副本、2 种不同存储介质、1 份异地备份
• rsync——高效的文件同步工具，支持增量传输、SSH 加密、断点续传
• tar——归档工具，常配合 gzip/bzip2/zstd 压缩使用
• mysqldump——MySQL/MariaDB 的逻辑备份工具
• pg_dump——PostgreSQL 的逻辑备份工具
• RPO（恢复点目标）——可接受的最大数据丢失时间（如 RPO=1h 意味着最多丢 1 小时数据）
• RTO（恢复时间目标）——从故障到服务恢复的最大可接受时间
• 异地备份（Off-site Backup）——将备份存储在不同地理位置，抵御机房级故障

知识关联

• 前置知识：3.6：MySQL 数据库 MySQL/MariaDB、3.7：PostgreSQL 数据库 PostgreSQL（数据库备份）、1.9：重定向与管道 重定向与管道
• 后续影响：备份是 4.13：服务器初始化规范 服务器初始化规范和 4.14：运维故障案例集 运维故障案例集的重要组成
• 配套技术：cron（定时任务）、rsync（远程同步）、对象存储（异地备份）

原理讲解

为什么 3-2-1 是黄金法则？

3-2-1 原则不是教条，而是对真实故障场景的经验总结：硬件故障（磁盘损坏）、软件故障（误删除、勒索病毒）和站点故障（火灾、网络中断）分别由"3 份副本"、"2 种介质"和"1 份异地"来防御。三个条件缺一不可——仅有多副本但全部在同一个房间，一场火灾就能摧毁所有备份。

为什么必须有"2 种不同介质"？

"2 种介质"防御的是共模故障（Common Mode Failure）。同一型号的硬盘、同一品牌的 NAS、同一云服务商的存储桶，都可能因为设计缺陷或系统性故障同时损坏。历史上发生过：某品牌 SSD 固件 bug 导致同批次硬盘在特定时间后批量失效；某云服务商的存储系统 bug 导致数据不可用数小时。如果所有备份都在同一种介质上，这种系统性故障会同时摧毁原始数据和所有备份。

常见组合：本地磁盘 + 云对象存储（S3/OSS）、本地 NAS + 异地 NAS、SSD + 磁带。关键是两种介质有不同的故障模式——磁盘可能机械故障，磁带可能磁性衰退，云存储可能服务中断。这种多样性才是冗余的真正含义。

为什么推荐 restic 而不是只用 tar + rsync？

tar + rsync 适合简单场景（小目录快照、配置文件备份）。restic 适合生产环境——去重节省存储、加密保护隐私、完整性校验防止数据损坏、保留策略自动清理旧版本。borgbackup 功能类似但远程目标需自建 SSH 服务器，restic 对云存储的支持更开箱即用。

为什么备份必须做恢复演练？

备份完成 ≠ 备份可用。真实案例：某公司每天执行 mysqldump 备份，持续运行了 3 年。服务器宕机后尝试恢复，发现备份文件全部损坏——因为磁盘有坏道，备份写入时就已经不完整了，但备份脚本没有校验步骤，从来没有发现过问题。

恢复演练验证的是整个恢复链路：备份文件是否完整 → 恢复脚本是否正确 → 恢复后的数据是否一致 → 服务是否能正常启动。任何环节出问题，真正的灾难发生时都会暴露。建议每季度做一次完整恢复演练，至少每月做一次抽样恢复验证。

RPO 与 RTO

设计备份策略前必须先定义两个目标：RPO 决定备份频率（每 1 小时备份 vs 每天备份），RTO 决定恢复方案（从本地恢复 vs 从异地恢复）。个人博客 RPO=24h、RTO=4h 可以接受；电商平台 RPO=5min、RTO=30min。预算和复杂度随 RPO/RTO 的降低而急剧上升。

全量、增量与差异备份

备份频率与存储成本的平衡靠这三种策略解决。以 30 天周期、每天数据变化 100MB 为例：

生产常用组合：每周日全量 + 每天增量（rsync/restic），保留 4 周全量 + 3 个月增量链。注意：增量链断裂往往只有真正恢复时才暴露，所以恢复演练要优先演练"最近时间点"的恢复路径。

示例代码

1. 文件级备份

# tar — 归档并压缩
tar -czf /backup/www_$(date +%Y%m%d).tar.gz /var/www
# 输出: （无输出）
tar -czf /backup/etc_$(date +%Y%m%d).tar.gz /etc/nginx /etc/mysql

# tar — 排除特定目录
tar -czf /backup/home.tar.gz --exclude="*.mp4" --exclude="node_modules" /home

# rsync — 本地同步（增量）
rsync -avz --delete /var/www/ /backup/www/
# 输出: sending incremental file list
# 输出: ./
# 输出: index.html
# 输出: sent 12345 bytes  received 35 bytes  24760.00 bytes/sec

# rsync — 远程同步（异地备份）
rsync -avz -e "ssh -p 22" /backup/ user@remote-server:/backup/

# rsync — 通过 SSH 隧道（压缩传输）
rsync -avz --progress /var/www/ user@10.0.0.5:/backup/www/

# 验证归档完整性
tar -tzf /backup/www_20260730.tar.gz > /dev/null && echo "Archive OK" || echo "CORRUPT"
# 输出: Archive OK

2. 数据库备份

# MySQL/MariaDB 备份（单库）
mysqldump -u root -p --single-transaction mydb | gzip > db_$(date +%Y%m%d).sql.gz
# 输出: Enter password:
# 输出: （备份完成，无输出到终端）

# MySQL/MariaDB 全库备份
mysqldump -u root -p --all-databases --single-transaction | gzip > all_db.sql.gz
# 输出: Enter password:

# PostgreSQL 备份
pg_dump -U postgres mydb | gzip > pg_mydb_$(date +%Y%m%d).sql.gz
# 输出: （无输出）

# PostgreSQL 全集群备份
pg_dumpall -U postgres | gzip > pg_all_$(date +%Y%m%d).sql.gz

3. 自动化备份脚本

#!/bin/bash -euo pipefail
# /usr/local/bin/backup.sh — 全自动备份脚本

BACKUP_ROOT="/backup"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=30
LOG_FILE="/var/log/backup.log"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] 开始备份" >> "$LOG_FILE"

# 1. 备份网站文件和配置
tar -czf "$BACKUP_ROOT/files_$DATE.tar.gz" /var/www /etc/nginx /etc/mysql

# 2. 备份数据库（用专用配置文件携带凭据，避免 cron 环境卡在交互式密码提示）
mysqldump --defaults-extra-file=/etc/mysql/backup.cnf --all-databases --single-transaction \
    | gzip > "$BACKUP_ROOT/db_$DATE.sql.gz"
#  /etc/mysql/backup.cnf 内容： [client] user=backup_user password=xxx （chmod 600）

# 3. 同步到异地（远程服务器）
rsync -avz --delete "$BACKUP_ROOT/" backup@10.0.0.5:/backup/monthly/

# 4. 清理 30 天前的旧备份
find "$BACKUP_ROOT" -name "*.gz" -mtime +$RETENTION_DAYS -delete

echo "[$(date '+%Y-%m-%d %H:%M:%S')] 备份完成" >> "$LOG_FILE"

4. 定时任务（cron）

# sudo crontab -e 添加以下行

# 每天凌晨 3 点执行完整备份
0 3 * * * /usr/local/bin/backup.sh

# 每 6 小时增量备份数据库（使用 rsync 或 mysqldump 的特定表）
0 */6 * * * /usr/local/bin/incremental_backup.sh

# 每月 1 日执行完整验证恢复
0 8 1 * * /usr/local/bin/verify_backup.sh

5. 灾难恢复清单

# 灾难恢复步骤（以 Web 服务器为例）
# Step 1: 准备新服务器
sudo apt update && sudo apt install nginx mysql-server
# 输出: Reading package lists... Done
# 输出: The following NEW packages will be installed:
# 输出:   nginx mysql-server

# Step 2: 恢复配置文件
sudo tar -xzf /backup/etc_latest.tar.gz -C /
# 输出: （无输出）

# Step 3: 恢复网站文件
sudo tar -xzf /backup/files_latest.tar.gz -C /

# Step 4: 恢复数据库
gunzip < /backup/db_latest.sql.gz | sudo mysql

# Step 5: 重启服务并验证
sudo systemctl restart nginx mysql
curl -I http://localhost
# 输出: HTTP/1.1 200 OK
# 输出: Server: nginx/1.24.0

6. 备份工具对比与选型

选型建议：配置文件和小目录用 tar；需要异地镜像且保留多版本用 restic（对 S3/OSS 等对象存储支持最好）；追求极致存储效率且自建备份服务器用 borgbackup。restic 和 borg 都内置校验，能发现静默损坏（bit rot），这是 tar/rsync 做不到的。

7. Restic：带加密与去重的现代备份工具

# 安装（Ubuntu）
sudo apt install restic

# 1) 初始化仓库（本地目录为例；也支持 s3:/b2:/rclone: 等远程目标）
restic init --repo /backup/restic-repo --password-file /etc/restic-pass
# 输出: created restic repository 4f2f9c4a at /backup/restic-repo

# 2) 创建快照（备份 /var/www 与 /etc/nginx）
restic backup /var/www /etc/nginx \
    --repo /backup/restic-repo --password-file /etc/restic-pass
# 输出: snapshot 7d2b4d1c saved
# 再次执行同一目录只上传变化块（去重后通常只有几 MB）

# 3) 列出快照
restic snapshots --repo /backup/restic-repo --password-file /etc/restic-pass

# 4) 保留策略：最近 7 天每天 1 个 + 4 周 + 6 月 + 2 年，并清理无用数据
restic forget --repo /backup/restic-repo --password-file /etc/restic-pass \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2 --prune

# 5) 恢复演练：恢复到临时目录并与源对比（重点！）
restic restore latest --target /tmp/restore-test \
    --repo /backup/restic-repo --password-file /etc/restic-pass
diff -r /var/www /tmp/restore-test/var/www && echo "恢复验证通过"

# 6) 校验仓库完整性（发现静默损坏）
restic check --repo /backup/restic-repo --password-file /etc/restic-pass

# 7) 定时任务：每天 2:30 备份 + 每周日清理
# sudo crontab -e
30 2 * * *  restic backup /var/www /etc/nginx --repo /backup/restic-repo --password-file /etc/restic-pass --tag nightly >> /var/log/restic.log 2>&1
0 3 * * 0  restic forget --repo /backup/restic-repo --password-file /etc/restic-pass --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2 --prune >> /var/log/restic.log 2>&1

密码文件一旦丢失，备份就永远无法解密——把密码存进密码管理器，并在异地额外保存一份。仓库 check 和恢复演练应纳入月度计划。

8. 数据库备份：逻辑备份 vs 物理备份与 binlog 增量

# MySQL 逻辑备份（--single-transaction 对 InnoDB 提供一致性快照，
# 备份期间不影响线上读写）
mysqldump -u backup -p --single-transaction --routines --triggers mydb | gzip > mydb_$(date +%F).sql.gz

# MySQL 物理备份（Percona XtraBackup，备份期间零锁表；
# 注意：xtrabackup 不在 Ubuntu 官方源，需加 Percona 仓库安装 percona-xtrabackup-80，
# 且仅支持 MySQL 8.0.x，不支持 8.4）
xtrabackup --backup --target-dir=/backup/xtra/ --user=backup --password=xxx
xtrabackup --prepare --target-dir=/backup/xtra/    # 恢复前必须 prepare

# PostgreSQL 物理备份（pg_basebackup，主库在线备份）
pg_basebackup -D /backup/pg_base -U backup -h localhost -P -X stream

# ===== binlog 增量备份：把 RPO 从 24 小时压到几分钟 =====
# MySQL 开启 binlog（/etc/mysql/mysql.conf.d/mysqld.cnf）
#   server-id = 1
#   log_bin = /var/log/mysql/mysql-bin.log
#   binlog_format = ROW

# 每天把当天产生的 binlog 复制归档
mysqlbinlog --read-from-remote-server --host=localhost --user=backup --password=xxx \
    mysql-bin.000123 mysql-bin.000124 | gzip > binlog_$(date +%F).sql.gz

# 恢复流程：先恢复最近全量，再按顺序重放 binlog 到故障前一刻
gunzip < mydb_20260727.sql.gz | mysql mydb
mysqlbinlog --stop-datetime="2026-07-30 09:58:00" mysql-bin.000123 mysql-bin.000124 | mysql mydb

生产建议：每天凌晨 mysqldump 全量 + 持续归档 binlog，故障时最多丢几分钟数据。全量备份保留 30 天，binlog 保留 7 天（与全量周期重叠，保证能回放到任意时间点）。

9. 备份验证体系：checksum 与恢复演练

备份完成 ≠ 备份可用。磁盘静默损坏、压缩工具版本差异都会让备份"看起来在，实际不能用"。验证体系分三层：

# 第一层：备份后立即校验（每次备份都做）
tar -tzf /backup/files_20260730.tar.gz > /dev/null && echo "OK" || echo "CORRUPT"
gzip -t /backup/db_20260730.sql.gz && echo "OK" || echo "CORRUPT"

# 生成并保存 checksum 清单（清单本身也要异地带一份）
sha256sum /backup/*.gz > /backup/checksums.txt
# 校验时执行：
cd /backup && sha256sum -c checksums.txt
# 输出: files_20260730.tar.gz: OK
#        db_20260730.sql.gz: OK

# 第二层：抽样恢复测试（每周）
mysql -e "CREATE DATABASE test_restore"
gunzip < /backup/db_20260730.sql.gz | mysql test_restore
mysql -e "SELECT COUNT(*) FROM test_restore.orders"   # 与线上行数对比
mysql -e "DROP DATABASE test_restore"                 # 演练后清理

10. 异地备份：rclone 同步到云存储

# 安装 rclone
sudo apt install rclone

# 交互式配置远端（支持 S3/OSS/COS/Google Drive 等 40+ 存储）
rclone config
# 输出: n) New remote
#      name> oss
#      Storage> 1            # 1.65.x 中 OSS 按名称排序位于第 1 位
# 注意：1.67+ 起 OSS 并入 "Amazon S3 Compliant Storage" 子菜单（按名称选择）；菜单序号随版本变化，按名称选择而非序号
# 按提示填入 AccessKey、Secret、Endpoint（如 oss-cn-hangzhou.aliyuncs.com）

# 同步本地备份目录到对象存储（--transfers 并发，--checksum 按哈希比对）
rclone sync /backup oss:my-bucket/backup --checksum --transfers 8 \
    --log-file /var/log/rclone.log --log-level INFO

# 上传后双向校验
rclone check /backup oss:my-bucket/backup --log-file /var/log/rclone-check.log
# 输出: 2026/07/30 03:00:01 INFO  : All files match

# 定时任务：每天 4 点同步 + 4:30 校验
# sudo crontab -e
0 4 * * * rclone sync /backup oss:my-bucket/backup --checksum --transfers 8 --log-file /var/log/rclone.log --log-level INFO
30 4 * * * rclone check /backup oss:my-bucket/backup >> /var/log/rclone-check.log 2>&1

对象存储天然满足"第二种介质 + 异地"：它是独立存储系统，且通常跨机房多副本存储。注意设置存储桶生命周期规则（如 90 天后自动转低频/删除），避免备份无限增长产生高额费用。另外建议为对象存储创建最小权限的专用子账号，AccessKey 泄露时损失可控。

常见错误

最佳实践

练习题

1. （概念）3-2-1 备份原则中的"3"、"2"和"1"分别代表什么？为什么需要"2 种不同介质"？
2. （概念）RPO 和 RTO 的区别是什么？对于一个日活 10 万的电商网站，你认为合理的 RPO 和 RTO 各是多少？
3. （实操）创建 /tmp/test_data/ 目录并放入几个文件。使用 tar 归档压缩，然后用 rsync 将其同步到 /tmp/backup/。最后用 tar -tzf 验证归档完整性。
4. （实操）修改自动化备份脚本，增加以下功能：备份完成后通过邮件或 Slack Webhook 发送通知，用 df 检查磁盘空间并在不足时跳过备份并报警。
5. （🔍 挑战）模拟"服务器被勒索病毒攻击"场景：将网站目录下的所有文件改为 echo "encrypted"，然后执行完整的恢复流程（从本地备份恢复）。之后在异地服务器练习远程恢复，用 rsync 将本地备份推送到异地，从异地服务器完成恢复并验证服务正常。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

备份是运维的最后一道防线。3-2-1 原则提供经得起真实故障考验的框架——3 份副本防硬件故障、2 种介质防同一故障模式、1 份异地防站点灾难。工具层面 tar、rsync、mysqldump/pg_dump 覆盖了文件和数据库备份的核心需求。自动化（cron + 脚本）、验证（定期恢复演练）和监控（备份失败告警）构成了完整的备份体系。记住：没有经过验证的备份不算备份。

速查表

学习路径建议

• 学完本章后阅读 4.13：服务器初始化规范 服务器初始化规范（备份是初始化的一部分）
• 备份系统设计可参考 3.12：系统监控与告警 系统监控方案（备份也需要被监控）

延伸阅读