Shirone

先纠正一个致命误区：备份 ≠ 同步#

很多人用「网盘同步」「RAID 1」「rsync 镜像」当备份，这些方案有一个共同的盲区：它们忠实地复制错误。

• 误删一个文件，同步工具立刻把副本也删了。
• 勒索软件加密了数据，RAID 的两块盘一起变成密文。
• 数据库写入了脏数据，镜像忠实复制了脏数据。

真正的备份必须能回答：「我想回到三天前的那个版本」——这需要历史版本和不可变性，是同步类方案给不了的。

3-2-1 原则#

经典的备份策略只有一句话：

• 3 份数据副本（生产数据 + 2 份备份）
• 2 种不同介质（如服务器磁盘 + 对象存储）
• 1 份在异地（防火灾、机房故障、云账号被封）

对一台个人云服务器，可落地的组合是：本地快照（快速恢复）+ 异地对象存储（灾难恢复）。成本不过每月几元，换来的是睡得着觉。

工具一：rsync 做本地快照#

rsync 是增量传输的瑞士军刀，适合做本机或内网的快速备份层：

1
rsync -avz --delete \
2
  --exclude={'/dev/*','/proc/*','/sys/*','/tmp/*'} \
3
  /var/www/ /backup/www-$(date +%F)/

关键参数：

• -a 归档模式（保留权限、时间戳、软链）
• -v -z 显示过程、传输压缩
• --delete 让目标与源一致（用前想清楚：源目录误删会同步到备份，这就是它只能算「快照」不能算唯一备份的原因）

配合 --link-dest 可以实现「占空间很小的每日全量快照」：未变化的文件用硬链接共享同一份数据，每天一个目录却几乎不占额外空间。

数据库备份注意：不能直接 rsync 数据目录——运行中的数据库文件处于不一致状态。正确顺序是先导出逻辑备份：

1
# PostgreSQL
2
pg_dump -U myapp myapp | gzip > /backup/db/myapp-$(date +%F).sql.gz
3

4
# MySQL
5
mysqldump --single-transaction -u myapp -p myapp | gzip > /backup/db/myapp-$(date +%F).sql.gz

（--single-transaction 对 InnoDB 做一致性快照导出，不锁表。）

工具二：restic 做加密、去重、版本化备份#

restic 是现代备份工具的代表：增量去重、端到端加密、支持 S3 兼容存储，一份数据加密后才离开服务器——就算存储端被攻破，攻击者拿到的也是密文。

初始化仓库（以 S3 兼容对象存储为例）：

1
export AWS_ACCESS_KEY_ID=xxx
2
export AWS_SECRET_ACCESS_KEY=xxx
3
export RESTIC_PASSWORD=备份仓库的加密口令
4

5
restic -r s3:https://s3.example.com/mybucket/backups init

日常备份一条命令：

1
restic -r s3:https://s3.example.com/mybucket/backups \
2
  backup /var/www /etc /backup/db \
3
  --exclude-file /etc/restic/excludes

restic 每次备份生成一个快照，自动去重——重复备份 100 GB 数据，第二次只传变化的部分。

保留策略：旧快照不是无限留的，按策略清理：

1
restic -r s3:... forget --prune \
2
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6

保留最近 7 个日备份、4 个周备份、6 个月备份，其余删除并回收空间。

定时化：把备份命令写成脚本，用 cron 或 systemd timer 每天凌晨执行，并把结果输出到日志，纳入监控告警——「备份任务失败」必须是一条会叫醒人的告警，静默失败的备份等于没有备份。

恢复演练：备份的真正验收#

没恢复过的备份只能算「愿望」。restic 的恢复：

1
# 列出快照
2
restic -r s3:... snapshots
3

4
# 恢复指定快照到临时目录（先在临时位置验证，别直接覆盖生产）
5
restic -r s3:... restore latest --target /tmp/restore-check
6

7
# 只取回单个文件
8
restic -r s3:... dump latest /var/www/config.yml > config.yml

建议每季度做一次完整演练：把备份恢复到一台干净的机器，验证应用真的能跑起来。演练会暴露各种想当然——比如备份里漏了某个关键目录、数据库导出脚本早就因为密码轮换而失败。

一张个人服务器备份方案清单#

1. 每日凌晨：pg_dump/mysqldump 导出数据库到本地目录。
2. 随后：restic 把「应用数据 + /etc 配置 + 数据库导出」加密备份到异地对象存储，保留 7 日/4 周/6 月。
3. 备份失败 → 触发告警，当天处理。
4. 每季度：恢复到测试环境演练一次。
5. 加密口令、存储密钥记录在离线的密码管理器里——备份全在，口令丢了，一样是数据丢失。

这套方案全部用开源工具和对象存储搭建，月成本一杯咖啡钱，换的是任何单点事故都不致命的底气。

延伸阅读#

• restic 官方文档
• rsync 手册页
• PostgreSQL 官方文档：Backup and Restore