备份这件事，只有在你真正需要恢复的那天才知道做对没做对
大多数人的“备份”是把文件复制到另一块硬盘。这不叫备份，这叫复制——它无法抵御误删、勒索软件加密、硬盘同时损坏这三种最常见的故障。
这篇教程给出一套可复现的方案：用 restic 做增量加密备份，存到对象存储（S3 兼容，如 Cloudflare R2、阿里云 OSS、MinIO），用 cron 每天自动跑，并定期验证可恢复性。全程不需要图形界面，配置一次长期有效。
为什么选 restic
同类工具里，restic 的取舍比较均衡：
| 工具 | 增量方式 | 加密 | 适合场景 |
|---|---|---|---|
| restic | 内容寻址分块去重 | 内置 AES-256 | 跨机器、跨云，长期归档 |
| rsync | 文件级差异 | 需配合 SSH/加密卷 | 本地或同网段同步 |
| tar + gzip | 全量 | 无 | 一次性打包 |
| 云盘同步 | 文件级 | 服务商托管 | 小文件、多端访问 |
关键在于 restic 的去重是内容级的：同一个文件改了一个字节，只上传变化的数据块。所以第一次全量之后，日常备份通常只有几十 MB，长期成本可控。
第一步：准备对象存储
在云厂商控制台创建一个私有 Bucket（不要开公共读），记下四个参数：
- Endpoint：如
https://xxx.r2.cloudflarestorage.com - Bucket 名称：如
my-backup - Access Key / Secret Key：建议单独创建一个只有该 Bucket 读写权限的子账号
务必用子账号而非主账号密钥——备份密钥泄露的风险远高于其他凭证，因为里面装的是你的全部数据。
第二步：安装与初始化仓库
Linux 下直接装：
- Debian/Ubuntu：
apt install restic - macOS：
brew install restic - Windows：
winget install restic，或用 WSL
设置环境变量（建议写进 ~/.restic-env 并 chmod 600）：
RESTIC_REPOSITORY=s3:https://endpoint/bucketRESTIC_PASSWORD= 一个足够长的强密码AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY
然后初始化：
restic init
这一步生成的密码必须离线保存（密码管理器 + 纸质各一份）。restic 没有找回机制，密码丢了，数据等于不存在。
第三步：第一次备份
最小可用命令：
restic backup /data /home/user/docs --exclude-caches --exclude '*.tmp'
几个实用参数：
--exclude-caches：跳过带 CACHEDIR.TAG 的缓存目录--exclude-file excludes.txt：把排除规则写进文件，便于维护--tag daily：给快照打标签，方便后续按策略清理--verbose：首次运行建议加上，观察上传量
跑完后用 restic snapshots 确认快照已生成，记录下快照 ID。
第四步：自动化与保留策略
写进 crontab（crontab -e），每天凌晨三点执行：
0 3 * * * . /root/.restic-env && restic backup /data --tag daily && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
这条策略的含义是：保留最近 7 天每日快照、4 个周快照、6 个月快照，其余合并清理。--prune 会真正回收空间，建议每周执行一次而不是每天，因为它需要读取较多索引数据。
第五步：验证，这是最容易被跳过的一步
没验证过的备份等于没有备份。两个动作，建议每月做一次：
- 完整性检查：
restic check --read-data-subset=5%，抽样校验数据块是否损坏 - 实际恢复：
restic restore latest --target /tmp/restore-test，恢复到一个临时目录，随便打开几个文件确认能读
恢复测试的意义在于验证路径结构与权限是否正确。很多人第一次真出事时才发现，恢复出来的目录层级和自己想象的不一样。
几个容易踩的坑
- 把备份仓库挂载在本机同一块盘上：硬盘挂了，备份一起没
- 用 root 跑 cron 但环境变量没加载：cron 的环境极简，必须显式 source 配置文件
- 对象存储开了版本控制又用 restic：两者叠加会产生额外费用，二选一即可
- 忘记密码：无解，只能重来
写在最后
这套方案的配置成本大约半小时，之后每月只需花五分钟做一次恢复验证。备份的价值不在于它跑了多少次，而在于它能被恢复多少次。
如果你现在还没有任何异地备份，今天就可以先把 Bucket 建起来。数据丢失从来不是“会不会”的问题，而是“什么时候”的问题。
你现在的备份方案是什么？有没有踩过恢复失败的坑？欢迎在评论区交流。
评论 (0)