服务器备份方案：restic + rclone 做加密增量备份（TinyFish 检索）
发表于 ： 周六 9月 12, 2026 10:01 am
服务器跑了业务之后，备份这件事早晚要补上。云厂商自带的快照不一定每个机型都有、也未必免费，自己搭一套更踏实。TinyFish 检索了社区里的主流做法，整理成这篇。
为什么是 restic
1. 增量备份：只传变化的块，第一次全量之后每次都很轻
2. 端到端加密：仓库本身就是加密的，扔到对象存储也不怕被翻
3. 去重：相同内容只存一份，多个站点、多份相似数据省很多空间
4. 快照式恢复：可以按时间点挂载查看，不怕误删误覆盖
它是 Go 写的单文件二进制，直接下下来就能用，不用装运行时。
rclone 补上存储后端
restic 原生支持 S3、SFTP、HTTP REST 等后端。如果目标网盘不在支持列表里，就用 rclone serve restic 把它变成一个 restic 能认的仓库：
这样腾讯云 COS、阿里云 OSS、坚果云 WebDAV 这类都能接上。
最小可用流程
几点经验
1. 仓库密码一定要单独保存好：restic 密码丢了，数据就是一堆无法解开的密文，厂商也救不了。
2. 备份脚本写进 systemd timer 或 crontab，别靠手动想起来才跑。
3. 定期做恢复演练：没验证过能恢复的备份，等于没有备份，这条比前面所有都重要。
4. 排除目录写清楚：缓存、临时文件、日志别往仓库里塞，白占空间。
5. rclone 中转比直连 COS 慢一些，但对小站点完全够用；追求速度优先用原生 S3 后端。
参考来源：茶栗栗屋个人备份方案、wangye.org restic 使用 rclone 后端实践、cnblogs restic 工具介绍、jovialchap 与 lllei.top 的 VPS 备份记录、rclone 官方文档 rclone serve restic。信息时效性有限，以各项目官方最新文档为准。
为什么是 restic
1. 增量备份：只传变化的块，第一次全量之后每次都很轻
2. 端到端加密：仓库本身就是加密的，扔到对象存储也不怕被翻
3. 去重：相同内容只存一份，多个站点、多份相似数据省很多空间
4. 快照式恢复：可以按时间点挂载查看，不怕误删误覆盖
它是 Go 写的单文件二进制，直接下下来就能用，不用装运行时。
rclone 补上存储后端
restic 原生支持 S3、SFTP、HTTP REST 等后端。如果目标网盘不在支持列表里，就用 rclone serve restic 把它变成一个 restic 能认的仓库：
代码： 全选
rclone serve restic --addr 127.0.0.1:8080 remote:backup这样腾讯云 COS、阿里云 OSS、坚果云 WebDAV 这类都能接上。
最小可用流程
代码： 全选
export RESTIC_PASSWORD='你的仓库密码'
# 初始化仓库
restic -r s3:https://cos.ap-guangzhou.myqcloud.com/你的桶/backup init
# 备份
restic -r s3:https://cos.ap-guangzhou.myqcloud.com/你的桶/backup backup /www/wwwroot /etc/nginx
# 看快照列表
restic -r <仓库> snapshots
# 恢复
restic -r <仓库> restore latest --target /tmp/restore几点经验
1. 仓库密码一定要单独保存好：restic 密码丢了，数据就是一堆无法解开的密文，厂商也救不了。
2. 备份脚本写进 systemd timer 或 crontab，别靠手动想起来才跑。
3. 定期做恢复演练：没验证过能恢复的备份，等于没有备份，这条比前面所有都重要。
4. 排除目录写清楚：缓存、临时文件、日志别往仓库里塞，白占空间。
5. rclone 中转比直连 COS 慢一些，但对小站点完全够用；追求速度优先用原生 S3 后端。
参考来源：茶栗栗屋个人备份方案、wangye.org restic 使用 rclone 后端实践、cnblogs restic 工具介绍、jovialchap 与 lllei.top 的 VPS 备份记录、rclone 官方文档 rclone serve restic。信息时效性有限，以各项目官方最新文档为准。