←
Blog
Awshgreen
archive
Article · 2026-09-22

Restic 备份不是备了就算：初始化、验证、恢复与保留策略

2 min read · #备份 #Restic #Linux #运维 #灾难恢复

备份最危险的误区是：命令执行成功，就以为数据已经安全。真正可靠的备份至少要回答四个问题：备到哪里、是否加密、备份是否完整、坏了以后怎么恢复。

Restic 适合小服务器的原因是：仓库加密、支持本地和 SFTP 等后端、可以按快照恢复，也提供 check 和保留策略。下面以 SFTP 仓库为例，所有密码和服务器地址都使用占位符，不要把真实凭据写进文章或 Git。

先准备一个权限清晰的环境文件

例如创建 /etc/restic/example.env，内容类似：

RESTIC_REPOSITORY=sftp:backup-user@backup-host:/srv/restic/example-vps
RESTIC_PASSWORD_FILE=/etc/restic/example-password

密码单独放在 /etc/restic/example-password，并限制权限：

sudo install -d -m 700 /etc/restic
sudo chmod 600 /etc/restic/example.env /etc/restic/example-password

初始化仓库：

set -a
. /etc/restic/example.env
set +a
restic init

仓库密码一旦丢失，Restic 无法替你解密数据。它不是登录密码，不能通过重置服务器账号来找回，所以密码文件必须进入另一套安全的备份体系。

备份什么，取决于服务如何恢复

静态博客、配置文件和上传目录通常可以直接备份：

restic backup \
    /etc/nginx \
    /etc/systemd/system \
    /srv/example-app \
    --tag example-vps

数据库不要只复制正在运行的数据目录。更稳妥的方式是先用数据库自己的工具导出一致性快照，再把导出的文件交给 Restic：

pg_dump --format=custom --file=/srv/example-app/shared/backups/app-$(date +%F).dump app
restic backup /srv/example-app/shared/backups --tag database-dump

如果备份 Docker 卷，也要先确认服务是否允许在运行中复制。对数据库来说，“文件被复制出来”和“文件可恢复”不是一回事。

先看快照，再做完整性检查

列出快照：

restic snapshots

检查仓库内部结构：

restic check

check 能发现索引或数据结构方面的问题，但日常不一定每次都读取全部数据。可以定期安排更彻底的读取校验，时间和流量要结合仓库大小安排。

一个实用的习惯是：备份任务结束后记录退出码，并在监控或邮件里报告失败；每周或每月再执行一次恢复抽查。没有失败通知的自动备份，往往只是把失败藏到了后台。

恢复到临时目录，而不是直接覆盖生产目录

假设要查看最新快照里的配置文件：

mkdir -p /tmp/restic-restore-test
restic restore latest \
    --target /tmp/restic-restore-test \
    --include /etc/nginx

先检查目录结构、文件权限和内容：

find /tmp/restic-restore-test/etc/nginx -maxdepth 2 -type f -print
nginx -t -c /tmp/restic-restore-test/etc/nginx/nginx.conf

真正灾难恢复时，建议按“新机器、依赖、配置、数据、服务”的顺序进行，而不是把整个备份直接解压覆盖当前系统。恢复目标越清晰，误覆盖的风险越低。

用保留策略控制仓库大小

例如只预览清理结果：

restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 12 \
    --prune \
    --dry-run

确认输出中的待删除快照符合预期后，再去掉 --dry-run：

restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 12 \
    --prune

forget 负责按策略移除快照，prune 负责回收已经没有快照引用的数据。prune 可能消耗明显的 CPU、磁盘和网络资源，而且通常需要额外的工作空间，最好安排在业务低峰期。官方文档也建议清理后再运行 restic check。

用 systemd timer 自动执行

备份脚本 /usr/local/sbin/example-backup 可以很简单：

#!/bin/sh
set -eu

. /etc/restic/example.env
export RESTIC_REPOSITORY RESTIC_PASSWORD_FILE

restic backup /etc/nginx /etc/systemd/system /srv/example-app --tag example-vps
restic check

给它执行权限：

sudo chmod 750 /usr/local/sbin/example-backup

服务文件 /etc/systemd/system/example-backup.service：

[Unit]
Description=Backup example application with restic

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/example-backup

定时器 /etc/systemd/system/example-backup.timer：

[Unit]
Description=Run example backup daily

[Timer]
OnCalendar=*-*-* 03:20:00
Persistent=true

[Install]
WantedBy=timers.target

启用并检查：

sudo systemctl daemon-reload
sudo systemctl enable --now example-backup.timer
systemctl list-timers example-backup.timer
sudo systemctl start example-backup.service
sudo journalctl -u example-backup.service -n 100 --no-pager

第一次上线时建议手动观察完整运行过程。自动化的价值是减少遗忘，不是让人永远不看结果。

一份真正有用的恢复演练

每隔一段时间做一次小规模恢复测试：

  1. 在临时目录恢复一个最新快照。
  2. 检查配置文件能否通过语法检查。
  3. 用数据库备份启动一个临时实例。
  4. 随机打开几个上传文件，检查权限和内容。
  5. 记录从发现故障到恢复服务需要多久。

如果只在出事当天第一次尝试恢复，最容易遇到的是缺少密码、缺少依赖、路径变化和权限不匹配。恢复演练不是浪费时间，而是把这些问题提前暴露出来。

参考资料