先说结论
如果你只有一台 VPS、又怕哪天手滑删库或者被入侵，restic 是我目前最愿意推荐的备份工具：一个二进制文件就能跑，备份全程加密、增量去重，本地硬盘、SFTP、S3 都能当仓库。昨天本站刚介绍过它（restic：加密增量备份标杆），这篇把“怎么真正用起来”讲全：建库、首备、恢复、留存策略、定时任务，以及我踩过的几个坑。
restic 是什么，为什么选它
restic 用内容寻址做去重：文件切块后按内容哈希存，相同内容只存一份。每天备份一次，一个月下来仓库体积远小于“每天全量复制一份”。所有数据进仓库前都用 AES-256 加密，仓库密码丢了就等于数据丢了——这是安全设计，也是最大的风险点，后面会反复提醒。
和 tar + rsync 手工脚本比，restic 省掉的是“自己拼增量、自己管版本、自己写恢复流程”这三件脏活。快照（snapshot）自带时间戳和标签，恢复时按快照 ID 或者 latest 指定，不用翻一堆带日期的文件夹。
第一步：安装与建库
Linux 上最省事是直接下载官方二进制，或者用包管理器：
# Debian/Ubuntu
sudo apt install restic
# 或直接用官方二进制
restic version
建库只需要一条命令，仓库可以是本地目录：
restic -r /backup/myserver init
执行时会让你设仓库密码。我的做法是把密码写进一个权限 600 的文件，再用环境变量或 –password-file 引用，不要把密码写进 cron 脚本正文，也不要写进公开的部署文档。密码文件示例：
chmod 600 ~/.restic-password
export RESTIC_REPOSITORY=/backup/myserver
export RESTIC_PASSWORD_FILE=~/.restic-password
设好这两个环境变量后，后面所有命令都可以省略 -r 和密码参数，脚本会干净很多。
第二步：第一次备份与查看快照
# 备份网站目录与数据库导出目录
restic backup /var/www /root/db-dumps --tag daily
# 列出所有快照
restic snapshots
第一次备份是全量，耗时取决于数据量；之后每次只传变化块，通常几分钟就完。备份前先想清楚“排除什么”：缓存目录、日志目录、 node_modules 这类能重建的东西，用 –exclude 写进排除文件，别让它们撑大仓库：
restic backup /var/www --exclude-file=/root/restic-excludes.txt
数据库不要直接备正在运行的数据文件。正确姿势是先 mysqldump/pg_dump 导出到一个目录，再让 restic 备这个导出目录。直接备热数据库文件，恢复出来很可能是不一致的。
第三步：恢复——没练过恢复的备份等于没备
恢复分两种：整库恢复和单文件恢复。
# 恢复最新快照到指定目录（不会覆盖原目录）
restic restore latest --target /tmp/restore-test
# 只恢复其中一个文件
restic restore latest --target /tmp/restore-test --include /var/www/html/wp-config.php
# 按快照 ID 恢复
restic restore a1b2c3d4 --target /tmp/restore-test
我强烈建议第一次备份完就立刻做一次恢复演练：把快照恢复到 /tmp，打开几个关键文件确认内容是对的、数据库导出文件能正常导入。很多人第一次真正需要恢复时才发现：备份任务一直在跑，但恢复出来的东西打不开。演练花 10 分钟，能省掉灾难当天的几小时。
第四步：留存策略，别让仓库无限膨胀
快照越攒越多，仓库迟早失控。restic 的 forget + prune 负责清理：
# 保留最近 7 天每天 1 个、最近 4 周每周 1 个、最近 6 个月每月 1 个，其余删掉并真正回收空间
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
注意 prune 会重写仓库，跑的时候别同时跑备份；大仓库 prune 可能耗时很久，放在半夜低峰期跑。我的习惯是备份每天跑、清理每周跑一次，分开两个 cron 任务，互不干扰。
第五步：定时任务与异地
单机备份只能防误删、防误操作，防不了硬盘挂掉和机房事故。至少做到“本地一份 + 异地一份”：
# 每天凌晨 2:30 备份
30 2 * * * /usr/local/bin/backup-daily.sh >> /var/log/restic.log 2>&1
脚本里先导出数据库、再跑 restic backup、最后把退出码写进日志；失败要能被发现——可以接一个简单的邮件或 webhook 通知，静默失败的备份任务最危险。异地仓库可以用 SFTP 指向另一台 VPS：
restic -r sftp:user@backup-server:/backup/myserver init
restic -r sftp:user@backup-server:/backup/myserver backup /var/www
S3 兼容对象存储同理，仓库地址换成 s3: 开头的形式即可，认证走环境变量。异地那份不用天天全量，restic 的增量机制决定了日常传输量很小。
踩坑清单（都是真实会遇到的）
- 密码丢了 = 仓库报废。restic 没有“找回密码”这回事，密码文件本身也要备份到安全的地方，最好是离线一份。
- 备份正在跑的时候不要同时跑 prune，两个任务抢锁会互相报错；cron 里把时间错开。
- 恢复目标目录要写空目录或新目录，别直接往原目录恢复，避免把正在运行的服务文件覆盖成旧版本。
- 备份前先 restic check 定期校验仓库完整性，静默损坏比没有备份更可怕：
restic check
- 大文件备份时留意仓库所在磁盘剩余空间，prune 期间需要额外临时空间，磁盘满了会中途失败。
问：restic 和 rsync 定时复制有什么区别？
rsync 解决的是“同步一份最新副本”，restic 解决的是“保留多个时间点的加密快照”。误删一个文件后，rsync 的下一次同步会把删除也同步过去，而 restic 可以回到删除之前的任意快照。对备份来说，时间维度的可回退比单纯复制重要得多。
站长点评
我写这篇的出发点很实际：本站自己就是一台 VPS 在跑，数据库和上传目录丢了就是真金白银的损失。restic 吸引我的不是功能多，而是“一个工具把加密、增量、快照、异地这四件事一次做对”。但我也要说清楚：工具只是工具，真正决定备份有没有用的是两件事——恢复演练做没做、密码管没管好。这两件做到了，restic 才算落地；没做到，跑再多备份任务也只是心理安慰。