restic：一条命令把数据备份成快照

周五晚上手一抖，rm 把三个月的实验数据删掉一半，这才发现「备份」只是心里的一句承诺，从来没落成动作。备份这件事难的不是命令，是坚持：全量拷贝占空间、改了文件就要重拷、拷出去的文件还是明文。restic 是一个 Go 写的命令行备份工具，把这些麻烦一次解决掉：增量、去重、加密、快照，四件事一条命令全做了。今天现查的数据很稳：37,162 star，最新版本 v0.19.1，前天还有提交。

项目名片

它解决什么问题

手动备份有三个老毛病：拷一次几个 G，第二天改一行代码又要全拷一遍；备份文件裸放在移动硬盘里，硬盘丢了等于裸奔；同一份文件改了十版，只有最后一版能找回来。restic 把备份变成「快照流」，流程如下：每次备份生成一个只占增量空间的快照，仓库整体加密，任何一次快照都能单独恢复。

它替掉的是手工 rsync 加 crontab 的朴素方案，替不掉的是存储本身——仓库还是要放在某块盘或某个对象存储上，异地容灾的通道也得你自己出（某些场景可替代云厂商备份服务，替不掉的是带宽和存储成本）。

核心机制

1. 内容寻址去重：数据按块切开，以内容哈希命名存储，相同内容全仓库只存一份（推断：备份大量重复文件或多次全量时省空间明显）。
2. 快照语义：每次 backup 生成独立快照，记录目录树和时间，恢复时按快照 ID 或 latest 取，天然带版本历史。
3. 仓库加密：写入前用 AES-256 加密，口令不设不用记，丢了口令等于丢了全部数据，官方文档反复强调这点。
4. 后端协议内置：本地路径、SFTP、S3 兼容对象存储、rclone 桥接的网盘，切换后端只是换个仓库地址前缀，命令行参数一行不用改。
5. 官方同时发布最小 Docker 镜像，容器里只带 restic 二进制，适合挂在宿主机上定时跑，也适合塞进已有的容器编排里当定时任务。

跑起来

Debian/Ubuntu 官方源里有，一行装好：

sudo apt-get install restic
restic version

macOS 换 brew，Fedora 换 dnf：

brew install restic
dnf install restic

初始化一个本地仓库并做第一次备份：

export RESTIC_REPOSITORY=/srv/backup
export RESTIC_PASSWORD=test-pass-2026
sudo restic init --repo /srv/backup
restic backup ~/documents --verbose

想直接备到 S3 兼容对象存储，换地址前缀即可：

export AWS_ACCESS_KEY_ID=你的AccessKey
export AWS_SECRET_ACCESS_KEY=你的SecretKey
restic -r s3:你的S3域名/bucket名 init

不想污染宿主机也可以用官方最小镜像，只需要挂两个卷：数据目录和仓库目录。官方文档特别提醒，容器每次启动的随机主机名会干扰快照记录，务必用 --hostname 固定一个：

docker pull restic/restic
docker run --rm --hostname myhost \
  -v /srv/backup:/srv/backup \
  -v /home:/data:ro restic/restic \
  backup /data/documents

从零到能用

1. 装好 restic，先跑 restic version 确认版本，apt 源里的版本可能落后官方 release，介意就下官方二进制。
2. 挑好仓库位置：本地目录、SFTP 主机或 S3 桶，把地址写进 RESTIC_REPOSITORY，口令写进 RESTIC_PASSWORD。
3. 跑 restic init 初始化仓库，第一次会生成配置和主密钥，之后永远不要再 init。
4. 跑 restic backup 加上要备份的目录，第一次全量，第二次开始只传变化块。
5. restic snapshots 看快照列表，restic restore latest --target /tmp/restore 验证能恢复。
6. 定期跑 restic forget --keep-last 7 --prune 清理旧快照，加进 crontab 每周错峰执行。

适合谁用 / 别用

适合要给开发机、家用服务器、VPS 做定时加密增量备份的人：命令全是原子的，写进 cron 就是一条流水线，做运维周报时「我们上了加密增量快照」也是有分量的项目。别用在这两类场景：一是给不会命令行的家人备照片，选图形界面的方案更合适；二是要求分钟级容灾切换的业务，快照备份是冷恢复，扛不了 RTO 秒级的指标。还有一类要掂量：数据量大、带宽窄的办公网环境，第一次全量上传可能要跑好几个晚上，先拿小目录试水再决定上不上。

三个真实的坑

1. 压缩功能只在仓库版本 2 上生效：0.17 才加入压缩，老仓库要先跑 restic migrate upgrade_repo_v2 升级格式，官方备份文档里初始化输出明确写着 version 2, compression level auto（issue #21，168 条评论，讨论五年才落地）。
2. 只能从本机推，不能从远端拉：想备份 N 台机器，得每台都装 restic，或者自己写 ssh 管道；issue #299「Allow pulling backups from remote servers」2016 年开着至今没实现，99 条评论。
3. 备份到 B2/S3 这类对象存储偏慢，网络差时尤其明显（issue #1383，84 条评论）；大仓库跑 forget --prune 吃内存，官方 FAQ 建议放在夜间低峰跑。

小结

回到周五晚上那个 rm：数据能不能活下来，取决于删掉之前有没有人替它拍过快照。restic 把「拍快照」的成本压到两条环境变量加一条命令，剩下唯一的变量是你有没有把它写进 crontab。今晚装上，先给最重要的那个目录拍第一张。

参考资料

• 仓库：https://github.com/restic/restic
• 文档：https://restic.readthedocs.io
• 版本：https://github.com/restic/restic/releases/tag/v0.19.1
• issue #21：https://github.com/restic/restic/issues/21
• issue #299：https://github.com/restic/restic/issues/299
• issue #1383：https://github.com/restic/restic/issues/1383