Ubuntu 系统系列 | 第 13 天（重访·第二季）：备份与恢复策略——企业级备份方案

第 13/30 天（重访·第二季）

引言

在第一季的第 13 天，我们学会了 rsync、tar、duplicity、borg 四个工具的基本用法，知道了「3-2-1 备份原则」这句口号。但真实的生产环境远比「跑一条 rsync 命令」复杂得多——你知道每天的备份到底有没有成功吗？数据库备份和文件备份的时间点一致吗？备份介质真的能读出来吗？机房失火或者勒索病毒把备份盘一起加密时，你还有退路吗？

本篇文章是第二季的重访，我们将从「会跑备份命令」跃升到「构建企业级备份体系」：把 3-2-1 原则落地成可执行的方案（含 3-2-1-1-0 进阶变体）、用 borg/restic 做加密去重备份并打通自动验证、解决数据库一致性备份这个头号难题、最后通过灾难恢复演练证明「备份真的能恢复」。如果你已经会用 rsync 和 tar，本文会告诉你如何让备份体系「看得见、验得了、恢复了」。

一、从口号到落地：3-2-1 原则的企业级实现

「3 份副本、2 种介质、1 份异地」只是起点。企业级备份体系在它之上还要回答三个问题：副本之间隔多久同步？备份数据有没有被加密？备份能不能扛住勒索软件？ 由此衍生出两个进阶变体：

• 3-2-1-1-0：在 3-2-1 基础上再加「1 份不可变（immutable）副本」和「0 错误（恢复演练验证过）」——不可变副本是抵御勒索软件的关键，攻击者即使拿到备份机权限也无法删除或篡改存量备份。
• RPO / RTO 指标：RPO（恢复点目标）回答「最多丢多少数据」，RTO（恢复时间目标）回答「多久恢复业务」。备份频率必须由 RPO 倒推，而不是「每天半夜备份一次」。

落地示例——先盘清楚自己的数据资产：

# 盘点服务器上的关键数据目录
du -sh /var/www /var/lib/mysql /home/user /etc /opt/*/data 2>/dev/null | sort -rh

# 输出示例
# 152G    /var/lib/mysql
#  38G    /var/www
#   9.2G  /home/user
#  1.2G   /opt/application/data
#  86M    /etc

根据 RPO 分级：数据库（RPO=15 分钟）需要高频增量 + 定期全量；Web 静态文件（RPO=24 小时）每日快照即可；/etc 配置（RPO=即时）每次变更后随手备份。没有 RPO/RTO 的备份计划，等于没有计划。

二、borg / restic：去重加密备份实战

第一季介绍了 borg 的基本用法，这里对比 borg 与 restic 两个现代去重工具，重点解决远程备份和多客户端集中管理两大生产场景。

2.1 restic：一条命令搞定加密远程备份

# 安装
sudo apt update && sudo apt install -y restic

# 初始化仓库（会要求设置密码，务必放入密码管理器）
restic init --repo sftp:backup@192.168.1.100:/srv/backup/restic

# 备份 /var/www（第一次为全量，之后自动增量去重）
restic -r sftp:backup@192.168.1.100:/srv/backup/restic backup /var/www 
  --exclude '*.log' --exclude 'cache/' --tag web

# 输出示例
# repository 7555a7d5 opened (repository version 2) successfully, password is correct
# created new cache in /root/.cache/restic
# Files:          8412 new,     0 changed,     0 unmodified
# Dirs:            523 new,     0 changed,     0 unmodified
# Added to the repo: 8.471 GiB
# processed 8412 files, 8.471 GiB in 1:21
# snapshot 8f3c2a1e saved

查看与恢复：

# 列出所有快照
restic -r sftp:backup@192.168.1.100:/srv/backup/restic snapshots --latest 5

# 恢复到指定目录（不覆盖现有文件，先试跑 --dry-run）
restic -r sftp:backup@192.168.1.100:/srv/backup/restic restore 8f3c2a1e 
  --target /tmp/restore-test --include /var/www/index.html --dry-run

# 挂载浏览（FUSE）
mkdir -p /mnt/restic && restic -r sftp:backup@192.168.1.100:/srv/backup/restic mount /mnt/restic

restic 杀招：多个客户端写同一个仓库互不干扰，天然适合「10 台服务器每晚各自备份到一台备份机」的拓扑；forget --prune 命令按保留策略清理旧快照并回收空间。

2.2 borg：本地全量 + 保留策略

borgg 在单机/单仓库场景依然高效，关键是 borg prune 的保留策略要写成「可读的声明」：

export BORG_PASSPHRASE='<your-passphrase>'

# 创建备份（压缩 + 去重）
borg create --stats --compression zstd,8 
  /backup/borg-repo::server-{hostname}-{now:%Y-%m-%d_%H:%M} 
  /var/www /etc /home/user 
  --exclude '/home/user/cache' --exclude '*.tmp'

# 保留策略：保留每日 7 个、每周 4 个、每月 6 个
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 
  --prefix='server-{hostname}-' /backup/borg-repo

# 输出示例
# Keeping archive: server-web-2026-08-30_02:00 (1.24 GB)
# Keeping archive: server-web-2026-08-31_02:00 (1.24 GB)
# Keeping archive: server-web-2026-09-01_02:00 (1.24 GB)
# Pruned 4 archives, freed 32.4 GB

关键实践：--compression zstd,8 在速度与压缩率之间取得平衡；prune 的 --prefix 必须与 create 的 archive 命名一致，否则会把别的备份集一起删掉——这是 borg 生产事故高发点。

三、数据库一致性备份：备份体系的头号难题

文件级备份最大的坑：MySQL 在写入中，直接从数据目录复制出来的文件可能是损坏的。数据库备份必须保证一致性，三种做法按可靠性排序：

3.1 方案 A：mysqldump 逻辑备份（最通用）

# 全量逻辑备份：--single-transaction 保证 InnoDB 一致性快照（不锁表）
mysqldump --single-transaction --routines --triggers --events 
  -u backup_user -p --all-databases 
  | gzip > /backup/db/full-$(date +%F).sql.gz

# 恢复演练：先建库再导入
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS test_restore"
gunzip -c /backup/db/full-2026-09-01.sql.gz | mysql -u root -p test_restore

配合 binlog 可实现时间点恢复（PITR）：

# 先在 my.cnf 开启 binlog（row 格式）
# [mysqld]
# log_bin = /var/log/mysql/mysql-bin
# binlog_format = ROW
# 恢复：全量 + 增量 binlog 到灾难发生前一刻
mysqlbinlog --stop-datetime="2026-09-01 14:30:00" /var/log/mysql/mysql-bin.000012 
  | mysql -u root -p

3.2 方案 B：LVM 快照一致性备份（本机零锁）

如果 MySQL 数据目录在 LVM 逻辑卷上，快照是无损备份最爱：

# 1. 创建 LVM 快照（秒级完成，业务无感）
lvcreate -L 20G -s -n mysql-snap /dev/vg00/mysql-data

# 2. 挂载快照并复制数据（复制期间业务正常写入，互不影响）
mkdir -p /mnt/snap && mount /dev/vg00/mysql-snap /mnt/snap
rsync -a /mnt/snap/ /backup/mysql-full-$(date +%F)/

# 3. 卸载并删除快照
umount /mnt/snap && lvremove -f /dev/vg00/mysql-snap

3.3 方案 C：restic 备份前的 fsync 保障

数据库自带的热备工具（mariadb-backup、pg_basebackup）会在备份结束时执行 fsync，把备份文件与事务日志对齐。用 restic 备份这些工具的输出，就同时获得了「一致性 + 去重 + 加密」：

# PostgreSQL 基础备份（流复制协议，零锁）
pg_basebackup -h localhost -U backup -D /var/backup/pg-base 
  -Ft -z -P --wal-method=stream

# 再用 restic 加密去重上传
restic -r sftp:backup@192.168.1.100:/srv/backup/restic backup /var/backup/pg-base --tag pg

铁律：永远不要直接备份数据库裸数据目录（不配合快照/热备工具的话）——你备份的可能是「正在写入中的一半文件」。

四、备份自动化验证：让备份「看得见」

「备份成功」≠「备份可用」。企业级体系必须加上三层验证，并接入监控告警：

4.1 脚本层：备份后立即校验

#!/bin/bash
# /usr/local/bin/verify-backup.sh
set -e
REPO="sftp:backup@192.168.1.100:/srv/backup/restic"

# 1. restic check：校验仓库完整性与加密
restic -r "$REPO" check --read-data-subset=5%

# 2. 试恢复关键文件到临时目录（不污染生产）
restic -r "$REPO" restore latest --target /tmp/verify 
  --include /var/www/index.html --include /etc/nginx/nginx.conf

# 3. 内容比对：检查关键文件是否与生产一致
diff /etc/nginx/nginx.conf /tmp/verify/etc/nginx/nginx.conf 
  && echo "VERIFY_OK $(date)" >> /var/log/backup-verify.log 
  || echo "VERIFY_FAILED $(date)" >> /var/log/backup-verify.log

4.2 监控层：失败即告警

把验证结果接入现有监控（Prometheus + Alertmanager 或简单的钉钉/邮件通知）：

# cron 每日 03:30 执行备份验证，失败时写入告警文件
30 3 * * * /usr/local/bin/verify-backup.sh 2>&1 | tail -1

# 结合 node_exporter textfile collector 暴露指标
/usr/local/bin/verify-backup.sh --prometheus 
  > /var/lib/node_exporter/textfile/backup.prom 2>&1

textfile 指标示例：

# HELP backup_last_verify_ok 最近一次备份验证是否通过 (1=ok)
# TYPE backup_last_verify_ok gauge
backup_last_verify_ok 1
backup_last_verify_age_seconds 86340

Grafana 面板加一条「备份验证失败」告警规则：backup_last_verify_ok == 0 持续 5 分钟，就触发告警。备份失败尤其要「及时」发现——等两周后恢复时才发现备份坏了，代价是灾难性的。

五、灾难恢复演练：证明「备份真的能恢复」

备份体系的最后一块拼图是 DR 演练。参考业界最佳实践，每月至少做一次：

1. 演练目标：从零环境恢复 Web 服务 + 数据库，RTO 目标 2 小时
2. 演练环境：一台全新 Ubuntu 服务器（或容器），不接触生产数据
3. 演练脚本：

# 恢复步骤 1：安装基础软件并恢复配置
sudo apt install -y nginx mysql-server
restic -r sftp:backup@192.168.1.100:/srv/backup/restic restore latest 
  --target / --include /etc/nginx/ --include /etc/mysql/ 2>/dev/null || true

# 恢复步骤 2：恢复数据库
gunzip -c /backup/db/full-$(date +%F).sql.gz | mysql -u root -p

# 恢复步骤 3：恢复 Web 文件
restic -r sftp:backup@192.168.1.100:/srv/backup/restic restore latest 
  --target / --include /var/www/

# 恢复步骤 4：业务自检
curl -sf http://127.0.0.1/healthz && echo "DR_DRILL_PASS $(date)" >> /var/log/dr-drill.log

1. 演练复盘：记录实际 RTO/RPO，与目标对比；找出「恢复手册没写/写错」的步骤，更新文档。演练中发现的问题，比灾难发生时发现的问题便宜一万倍。

总结与下期预告

企业级备份体系不是「更复杂的命令」，而是把备份变成可量化、可验证、可演练的工程：盘清数据资产并定义 RPO/RTO（3-2-1-1-0）、用 borg/restic 做加密去重备份、用 LVM 快照和热备工具解决数据库一致性、用自动校验 + 监控告警让备份失败「立刻可见」、用月度 DR 演练证明恢复能力。记住三个立即可用的要点：数据库永远不要裸复制数据目录、restic check + 试恢复要进 cron、每月至少演练一次完整恢复。

下期预告：第 14 天（重访·第二季）将带来《系统更新与升级管理——生产环境升级策略》，深入 apt 安全补丁策略、do-release-upgrade 的完整升级流程、内核 Livepatch 与升级回滚方案。敬请期待！

系列目录