硬盘会坏、机房会淹、人会误删、商家会跑路——数据丢失的方式有无数种，备份的方法论只有一套。这篇把个人和小团队的备份体系讲透：策略、工具、加密、恢复演练。配合应急场景见安全应急响应完全手册。

一、核心原则：3-2-1 备份法则

业界铁律，先背下来：

3 份副本，2 种介质，1 份异地。

• 3 份：1 份生产数据 + 2 份备份——只拷一份的"备份"和原数据同生共死
• 2 种介质：别全在一块硬盘上（SSD + 对象存储，或两块不同批次的盘）
• 1 份异地：机房火灾、机器被偷、误操作 rm -rf，异地备份是最后的底线

个人/小团队的最小实践：

生产服务器（本地日备份）
   └─> 异地备份 1：对象存储（每周）
         └─> 异地备份 2：另一家云/家里 NAS（每月归档）

对象存储成本极低（几十 GB 一年几十块），异地备份没有借口。

二、备份什么：比你想的多

只备份数据库是不够的。完整的备份清单：

凭据备份的纪律：单独加密存放（密码管理器 + 加密压缩包），别明文躺在服务器上——备份文件本身泄露 = 全部钥匙泄露。密码管理见Vaultwarden 自托管。

三、策略：多久备一次、留多久

频率

保留期： grandfather-father-son

• 日备份：保留 7 天（son）
• 周备份：保留 4 周（father）
• 月备份：保留 12 个月（grandfather）

好处：任意"上周三"或"上个月"都能恢复，磁盘占用可控。清理旧备份要自动化——手动删的备份体系，三个月后一定乱。

四、工具：按场景选

1. rsync：文件备份的瑞士军刀

# 每日增量同步到异地（只传变化的）
rsync -avz --delete /data/ backup@备用机:/backup/prod/

# 排除不需要的
rsync -avz --exclude='*.tmp' --exclude='cache/' /data/ backup@:/backup/

简单可靠，配合 cron 就是一套方案。详细实践见Rsync 备份实战。

2. restic/borg：带版本和去重的现代备份

比 rsync 强的地方：加密、去重、快照版本、校验完整。

# restic 示例：初始化仓库 + 每日快照
export RESTIC_PASSWORD=你的加密密码
export RESTIC_REPOSITORY=sftp:backup@备用机:/backup/restic

restic init
restic backup /data /etc/nginx          # 备份
restic snapshots                        # 看历史
restic restore latest --target /restore # 恢复到指定目录

restic 的安全红利：备份文件本身加密——备份服务器被拖走也读不出内容，适合备份到不完全可信的位置。

3. 数据库专用：别用拷文件的

MySQL 正在写入时直接拷数据文件 = 备份可能损坏。用数据库自己的机制：

# 逻辑备份（通用，文件可直接读）
mysqldump -u root -p --single-transaction --all-databases | gzip > all-$(date +%F).sql.gz

# 物理备份（大库更快，需工具）
xtrabackup --backup --target-dir=/backup/xb-$(date +%F)

完整方案见MySQL 备份与恢复实战；主从架构下的备份从库备，不拖累主库，见MySQL 主从复制。

4. 云快照：用，但别只依赖

云厂商快照一键整机，适合变更前打点、快速回滚。但它是"单点备份"——和原数据在同一家云，商家跑路/区域故障时一起没。快照 + 异地备份，双轨并行，见云快照实战。

五、加密与安全

备份是敏感数据的全集，安全等级要高于生产：

1. 传输加密：rsync/restic 走 SSH，别用明文协议
2. 存储加密：restic/borg 默认加密；对象存储开服务端加密
3. 访问最小化：备份账号只能写备份目录，不能登录干别的（usermod -s /usr/sbin/nologin + 强制命令）
4. 密钥分开放：加密备份的密码存密码管理器，别和备份放同一台机器

六、恢复演练：备份体系的期末考试

没有恢复过的备份，等于没有备份。 这话每个运维都听过，然后继续不演练。

每季度一次，按真实事故场景走：

# 演练脚本：从备份完整恢复一个服务
# 1. 新起一台干净机器
# 2. 拉取最近一次异地备份
restic restore latest --target /restore-check
# 3. 导入数据库、放回文件、改配置
# 4. 起服务，跑健康检查
curl -f http://127.0.0.1/health
# 5. 计时：从零到服务恢复，用了多久？

验收标准：恢复时间（RTO）和数据完整度（抽查关键表行数、文件数）。演练发现的问题——备份文件损坏、密码没人知道、缺一份配置——都是真实事故的预演。见重装系统保留数据和高可用架构入门的演练章节。

七、备份监控：别让备份悄悄失败

备份失败是静默的——cron 挂了、磁盘满了、密码过期，没人知道，直到恢复时才发现三个月没备份。最低监控：

# 备份脚本末尾自检：失败即告警
restic snapshots --latest 1 > /tmp/latest.txt
SNAP_DATE=$(stat -c %y /tmp/latest.txt 2>/dev/null || echo "")
# 检查最新快照是否超过 26 小时（每日备份前提下）
find /backup -name "*.sql.gz" -mtime -1 | grep -q . || {
  echo "备份异常：24 小时内无新备份" | mail -s "BACKUP FAILED" admin@yourdomain.com
}

更系统的监控告警体系见Prometheus 监控入门。

八、备份检查清单（打印贴墙）

[ ] 核心数据有异地备份（不在同一台机器/同一家云）
[ ] 备份频率匹配数据重要性（数据库日备 + 存档日备）
[ ] 保留策略是自动清理的（日/周/月三层）
[ ] 备份有加密，密码不在备份机上
[ ] 数据库用专用工具备，不是拷文件
[ ] 凭据/密钥单独加密备份
[ ] 配置和部署文档在 Git 里
[ ] 备份失败有告警通道
[ ] 每季度做过一次真实恢复演练
[ ] 恢复流程有文档（写给三个月后的自己）

十条全勾，你的数据就真的丢不了了。

结语

备份体系的本质是和时间赛跑：RTO（多快恢复）和 RPO（丢多少数据）两个数字定策略，3-2-1 法则定架构，定期演练保底气。一套跑通的备份，是你在硬盘损坏、商家跑路、自己手滑时唯一的救命稻草——别等到需要它的时候才想起它。

需要搭备份体系的服务器，可以看看财富云计算：NAT 型云服务器 SSD 系统盘 + 快照、支持热升级，价格比独立 IP 机型省一半以上——配一台备用机做异地备份，主备组合成本可控， NAT 型跑自用服务和备份接收都刚好对症。

延伸阅读

1. Homepage 个人仪表盘：把散落各处的服务收进一个首页
2. SSL 证书完全指南：免费证书、自动续期与不过期监控
3. 压测与容量规划：上线前就知道你的服务器能扛多少人
4. AdGuard Home 内网 DNS：全家去广告、防劫持、内网解析一站解决
5. Hugo 静态博客搭建：秒开的博客，部署只要一个目录
6. 安全应急响应完全手册：服务器被入侵后，按这个流程走
7. 游戏服运营完全手册：从开服到停服，把一台服务器运营成百年老店
8. Loki 日志体系搭建：轻量级日志聚合，Grafana 里查遍所有服务器

更多阅读

1. 上一篇：压测与容量规划：上线前就知道你的服务器能扛多少人
2. 下一篇：SSL 证书完全指南：免费证书、自动续期与不过期监控