自建服务的备份策略：3-2-1 法则实践
当磁盘损坏、目录被误删或主机无法启动时，备份的价值只取决于一件事：能不能按预期恢复。
自建服务里最常见的误区有两个：把同步当备份，把快照当兜底。备份讨论的核心不是“存过一份”，而是“出事后能不能恢复”。
先把 3-2-1 说清楚
3-2-1 法则很简单：
- 3 份数据：原始数据之外，至少还有 2 份副本
- 2 种介质：不要都放在同一类设备上
- 1 份异地：至少有 1 份不和主机放在同一个地点
这里的“介质”更准确地说是不同故障域。比如主机内置盘 + NAS + 对象存储，就是三处副本、两类以上介质，并且包含异地副本。
对 Homelab 来说，它主要覆盖三类风险：
- 误删或误改
- 磁盘或整机损坏
- 同地事故，例如断电、进水、误操作连带清空
先分清什么值得备份
不是所有内容都要同等对待。ISO、影视缓存、容器镜像和关键业务数据，恢复价值并不一样。
更实用的做法是按恢复成本分类。
第一类：必须保
- 数据库
- 文档、照片、笔记
- 配置文件
- 反向代理配置、证书、自动化脚本
- 应用数据目录
这类内容容量未必大，但重建成本高。
第二类：可重建
- 容器镜像
- 下载缓存
- 临时转码文件
- 可重新拉取的安装包
这类内容丢失后会带来麻烦，但通常可以重新下载或再生成。
分类的意义很直接：优先保护不可替代的数据。
一套够用的落地方案
如果是普通 Homelab，不追求企业级复杂度，可以按下面的方式拆分。
本地第一份：主机原始数据
这是正在运行的数据，不算真正的备份副本，但它是整个方案的起点。
本地第二份：同网段另一台设备
常见做法是备份到 NAS，或者另一块独立硬盘。重点不是访问方便，而是独立存放。
适合备份的内容包括：
/etc这类配置目录- 容器编排文件
- 数据卷目录
- 数据库导出文件
数据库不要直接复制正在写入的数据文件。更稳妥的做法是先导出，再备份导出结果。
异地第三份：对象存储或远端设备
这一份用于防止同地事故。对象存储、异地 VPS 挂载存储、放在其他地点的低功耗机器都可以。
如果预算有限，至少把最关键的数据异地化，例如：
- 照片
- 文档
- 密码库导出文件
- 关键配置
- 数据库定期快照
不必把所有内容都放到云端，关键是最难重建的部分必须异地保存。
备份里最容易漏掉的三件事
1. 版本保留
如果备份里永远只有一份最新文件，误删、勒索或脚本错误都可能把“最新状态”一起污染。
因此需要保留历史版本。一个常见做法是：
- 每日保留 7 份
- 每周保留 4 份
- 每月保留 3 到 12 份
这不是固定标准，但明显好于持续覆盖同一份文件。
2. 校验
文件传过去，不代表内容一定可用。校验的目标是确认备份副本完整且可读取。
至少要确认两件事：
- 备份任务是否成功结束
- 备份文件是否可读、可解压、可导入
3. 恢复演练
恢复必须经过实际验证，不能只看任务日志。
建议定期做小规模恢复测试：
- 随机抽一个目录恢复
- 把数据库导入临时环境
- 用恢复出的配置重新拉起一个容器
如果从未做过恢复演练，这套备份只能算“看起来存在”。
自动化可以做，但别一把梭
常见工具很多，rsync、restic、borg、文件系统快照都可以。核心要求只有两点：
- 能按计划执行
- 能在失败时被及时发现
自动化至少应包含：
- 定时任务
- 失败通知
- 日志留存
- 旧版本清理
通知很关键。没有通知的定时任务，通常会在真正需要恢复时才暴露问题。
另外，脚本要尽量保持幂等。也就是：重复执行不会把现场变得更糟。例如重复创建目录、重复上传、重复清理时，不应产生额外破坏。
一个适合普通使用者的最小清单
如果现在还没有系统备份，可以先做到这几条：
- 列出关键数据目录
- 数据库改为“先导出再备份”
- 本地保留一份独立副本
- 异地再放一份精简版关键数据
- 设置版本保留策略
- 每月至少做一次恢复测试
下一步更值得单独展开的，不是“怎么多存一份”，而是先明确恢复目标：你能接受丢多少数据，又能接受服务停机多久。