自建服务的备份策略：3-2-1 法则怎么落地
当 ls /srv 下面已经堆满目录时，真正的问题不是“怎么存”，而是“坏了以后先救哪个”。
自建服务做久了，数据会越来越杂：照片、文档、数据库、配置文件、容器编排文件、反向代理配置、证书。把数据同步到另一块盘，通常只能算“复制”，不等于“备份”。误删、勒索、配置写坏、同步把错误一起带过去，这些场景里，复制经常救不了急。
先把 3-2-1 说成人话
3-2-1 法则可以拆成一句话：
- 至少有 3 份数据
- 放在 2 种不同介质
- 其中 1 份离开本机
这里的“介质”不用理解得太复杂。机械硬盘、SSD、对象存储、另一台机器，都可以算。重点不是凑数字，而是避免“一个地方出事，所有副本一起没”。
对 Homelab 来说，最常见的误区有两个。
误区一：RAID 不是备份
RAID 解决的是硬盘坏一块时系统还能继续跑，不解决误删、误覆盖、恶意加密、配置出错。
它提高的是可用性，不是可恢复性。前者是“别停机”，后者是“停了也能回来”。
误区二：同步不是备份
双向同步尤其危险。今天删错一个目录，明天发现时，另一边通常也已经跟着删了。
所以备份最好具备两个特性：
- 版本：能回到昨天、上周、上个月
- 不可变窗口：一段时间内不能被随意改写或删除
在 Homelab 里，先分级，再定策略
自建环境里，并不是所有数据都该用同一套备份方式。更稳妥的做法是先分级。
第一类：必须优先恢复的数据
比如：
- 照片、文档、笔记
- 数据库
- 媒体库的元数据
- 密码库
- 重要证书与密钥文件（密钥内容本身需加密保存）
这类数据体积未必最大，但恢复价值最高。
第二类：可以重建的服务配置
比如：
docker-compose.yml- 容器环境变量模板
- 反向代理配置
- 自动化脚本
- 定时任务配置
这类内容适合放进 Git，但 Git 也不是完整备份。仓库本身仍然需要备份，尤其是自托管时。
第三类：可再下载的大文件
比如公开镜像、可重新刮削的媒体文件、缓存目录。
这类内容不一定要高频备份，否则会明显抬高存储成本和带宽压力。很多时候，备份“索引和元数据”比备份整个文件集合更划算。
一个普通用户也能执行的落地版本
如果不想一开始就上复杂方案，可以先用这个组合。
本机一份：工作副本
就是正在运行的服务数据。
局域网一份：定时备份到另一台机器或 NAS
建议每天至少一次，重要数据库可以更频繁。
这里尽量不要用“覆盖式复制”，而要用带快照或版本的方式。
“快照”可以理解为某个时间点的存档，能在文件被改坏后回退。
异地一份：云端或异地设备
这份的重点不是快，而是“本地整机出事时还在”。
常见放法：
- 对象存储
- 异地 NAS
- 定期插上的离线硬盘
如果预算有限，异地那份可以只放高价值数据，不必全量搬走。
备份频率，按“能接受丢多少”来定
别先问“一天备份几次”，先问自己：
最多能接受丢掉多久的数据？
也就是恢复点目标。简单理解，就是“最坏情况下你愿意退回到几点”。
一个实用的粗分法：
- 文档、照片、密码库：每天，或实时同步后再做版本备份
- 数据库：每天一次全量，外加更高频增量或导出
- 配置文件：每次变更后立即提交并备份
- 媒体大文件：每周或每月做检查式备份
数据库要特别注意：直接复制正在运行中的数据库目录，未必可恢复。更稳妥的方式通常是先导出，再备份导出文件。具体命令取决于数据库类型，本文不展开。
备份不是结束，恢复演练才算闭环
很多备份策略的问题，不在“没备份”，而在“从没恢复过”。
至少应该验证三件事：
- 文件能不能找到
- 备份能不能解密
- 目标服务能不能真正启动起来
一个实用的办法是定期挑一个小服务做恢复演练：
- 在临时目录恢复配置
- 导入一份数据库备份
- 看容器能否正常启动
- 检查应用数据是否完整
这样能更快发现问题：缺了环境变量、漏了证书、脚本路径写死，或者备份里根本没有最新配置。
更值得先补的三处短板
1. 把“配置”和“数据”分开
很多人把容器、数据库、下载目录全堆进一个卷里，备份时很难分辨什么重要。
分开后，策略才能细化：配置小而重要，数据大而变化快，处理方式本来就不该一样。
2. 记录恢复顺序
不是所有服务都能“一键回来”。
例如先恢复数据库，再恢复依赖它的应用，最后再挂代理和证书。
顺序不写下来，过一段时间自己也容易忘。
3. 留意备份系统本身的单点
备份服务器、加密密码、访问凭据、任务调度，都可能成为新的单点故障。
尤其是加密备份时，如果密码只有一份，等于没备份。密码保存方式需要单独设计，并与数据备份区分开。
工具不是重点，边界才是重点
这篇不推荐“唯一正确”的工具，因为不同环境差异很大：文件型数据、数据库、虚拟机镜像、对象存储，适合的方案都不一样。
但有一条判断标准很实用：
如果你不能很快说清楚“某个目录删了以后怎么找回”，那备份策略大概率还没成型。
比起继续加工具，更值得继续细化的，往往是不同类型数据的保留周期：保留 7 天、30 天、180 天，分别该怎么取舍。