restic VPS 备份恢复教程：加密仓库、校验与演练

restic VPS 备份恢复教程：加密仓库、校验与演练

这篇 restic VPS 备份恢复教程把重点放在可恢复性，而不是只让定时命令显示成功。restic 支持本地、SFTP、S3 兼容对象存储、B2、Azure Blob 等后端，并在仓库中加密数据。仓库密码一旦丢失无法替代恢复，因此密码保管与备份本身同样重要。

开始前可先阅读Docker Compose 数据备份与恢复和systemd 服务自动重启教程，确定应用一致性和定时任务运行方式。

准备仓库与凭据

安装官方发行包或经过校验的二进制，设置 RESTIC_REPOSITORY 指向远端仓库，并通过权限严格的密码文件或受控密钥服务提供密码。不要把密码直接写入所有用户可读的脚本，也不要把对象存储密钥提交到代码仓库。

执行 restic init 只初始化一次。随后运行 restic snapshots 确认能够访问仓库。仓库密码应保存在独立的安全位置，并准备第二份受控副本；只有仓库数据而没有密码无法完成恢复。

创建首份备份

先列出需要保护的配置、用户数据和应用数据，排除缓存、临时文件、挂载的远端仓库及可重建内容。用 restic backup 创建快照，并通过标签和主机名区分服务。执行前可使用 dry-run 检查范围。

数据库不能只依赖复制正在变化的数据文件。应使用数据库原生导出、快照或一致性钩子，将得到的备份文件交给 restic。容器卷也要先确定一致性策略，避免得到结构完整但业务不可用的数据。

定时运行与失败处理

用 systemd timer 或受控调度器执行备份，服务账户只授予读取源目录和写入目标仓库所需权限。记录退出码和日志，并在失败时告警。不要把“定时器已触发”误当成快照已创建。

任务完成后运行 restic snapshots，确认最新快照时间、主机和路径。网络中断或权限错误应保留失败状态，自动重试要限制次数，防止凭据错误造成持续请求。

完整性检查

定期执行 restic check 检查仓库结构与索引。需要读取数据包验证时可使用更深入的检查选项，但会增加流量和时间，应安排维护窗口。任何错误都应先保全仓库副本，再按官方排障流程处理。

检查成功证明仓库结构在检查范围内一致，却不证明应用能够正常恢复。还需要将快照还原到隔离目录或测试实例，并运行应用级验证。

恢复演练

用 restic restore latest --target 目标目录 将最新快照恢复到空目录，避免覆盖生产文件。检查属主、权限、符号链接、配置和数据完整性，再按应用启动顺序恢复服务。

演练应记录恢复点、恢复步骤、依赖凭据和所需时间。若恢复必须依赖原 VPS 上唯一存在的配置或密钥，那么异地备份方案仍不完整。

保留与清理策略

使用 forget 按 daily、weekly、monthly 等规则选择保留快照，先加 --dry-run 查看将被删除的内容。prune 会回收不再引用的数据并重写仓库内容，运行前应确认空间、网络和备份窗口。

不要把 forget --prune 当成每天必须执行的动作。备份、检查、恢复演练和清理可以按不同周期安排，降低大规模维护操作对生产任务的影响。

安全与灾难恢复边界

远端仓库凭据应尽量限制权限，防止被入侵的 VPS 同时删除所有历史。可使用对象锁、不可变存储或第二仓库降低单一凭据风险，并定期测试第二路径。

最终检查包括：最新快照存在、告警可达、仓库检查通过、密码可取得、隔离恢复成功、保留策略符合业务要求。只有这些环节都被验证，备份才真正具备灾难恢复价值。