restic 怎样恢复指定目录并验证文件完整性？

从快照里找准目录，恢复到全新的隔离位置，再检查内容、权限与使用结果。本文给出 Linux 文件备份的命令示例和失败判断。

直接答案：先按主机和备份路径筛选快照，固定快照 ID，用 restic ls 确认快照内部路径；随后用 restore --include 把指定目录恢复到新的目标目录，并启用 --verify。恢复后仍需核对样本版本、文件内容、访问权限与业务读取。普通 check、恢复命令退出成功和“文件能打开”，各自只能证明部分条件。

适用环境与开始前的门槛

这套步骤适用于已经存在 restic 仓库、需要恢复一组普通文件的企业 Linux 环境，例如部门共享资料或应用导出文件。示例平台为 Linux、Bash、GNU coreutils；命令按 restic 0.19.1 官方文档核对。旧版本先查看本机帮助，不支持的参数不要直接套用。下文路径、ID 和容量均为操作示例，执行时替换为本机环境的值。

正在运行的数据库、虚拟机镜像和整机灾难恢复需要各自的一致性备份与恢复流程。本文不以复制数据库数据目录证明数据库可恢复。还没有定义恢复目标的企业，可先看企业备份恢复演练方法，明确可接受的数据损失和恢复时间。

建议恢复目标使用支持 Unix 元数据的本地 ext4/XFS 文件系统。FAT/exFAT、部分网络挂载及跨操作系统恢复可能无法表达原有所有者、权限或扩展属性，需要另设验收边界。仓库中去重压缩后的占用不能直接当成目标容量。

图：指定目录恢复路径：快照中的 /srv/company-docs 恢复到新目标后，位于 /srv/restore-drill/run01/srv/company-docs。--verify 校验恢复文件，权限与业务读取仍需继续验收。图内路径和 ID 为操作示例，目标须事先确认为空。 查看高清原图

第一步：核对版本，固定需要的快照

在有权访问仓库的演练终端执行。以下仓库地址 /mnt/backup/restic-repo、主机名 filesrv01、备份路径 /srv/company-docs 都要替换。restic 在终端交互询问仓库密码；不要将密码写到文章、命令行历史或演练报告。云存储与 SFTP 的连接设置沿用已经批准的访问方式。安装和后端要求见官方安装说明与仓库准备说明。

restic version
restic restore --help
restic -r /mnt/backup/restic-repo snapshots \
  --host filesrv01 --path /srv/company-docs
restic -r /mnt/backup/restic-repo snapshots --json \
  --host filesrv01 --path /srv/company-docs

JSON 输出中的 id 字段提供完整快照 ID；不要把短 ID 误记为完整 ID。查看快照时间及时区、Host、Paths、Tags，选择事故前且符合恢复目标的快照，记录完整 ID。这里的 --path 筛选快照；它不是恢复内容的过滤器。latest 在多主机、多任务仓库里可能指向另一组数据，本例后续固定 ID，不自动追随最新快照。

下面的 SNAPSHOT_ID 是占位符，必须替换为真实 ID 后才能执行。

restic -r /mnt/backup/restic-repo ls SNAPSHOT_ID

预期能在快照树中找到 /srv/company-docs 及其子文件。备份时用了相对路径，快照内部布局可能不同；以 ls 输出为准。路径不在树中时，先重新选快照或核对备份范围，不修改命令去猜目录。快照与路径说明见官方恢复文档。

第二步：区分仓库检查与实际恢复

普通仓库检查用于发现结构问题；完整读数据校验还会读取 pack 数据。后者可能耗时并产生云存储流量费用，应安排窗口。根据仓库大小选择完整检查或按份额轮转；只抽查了一部分，报告必须保留覆盖范围。官方仓库检查说明解释了这种区别。

restic -r /mnt/backup/restic-repo check
  # 完整读数据检查；安排合适的维护窗口后执行
restic -r /mnt/backup/restic-repo check --read-data

例如 check --read-data-subset=1/5 只检查一组 pack，不能写成全仓库数据校验。完整检查读的是仓库存储数据，仍没有证明恢复目标有足够空间、权限可重建、文件版本正确或应用能使用。出现损坏、缺失对象或非零退出码时停止验收，保留日志并调查后端、网络与仓库；不要为了让报告变绿直接运行 repair、prune 或 unlock。

第三步：在新目录预览，再恢复指定目录

以下块使用 Bash。先核对 /srv/restore-drill 所在挂载点，并由管理员准备一个专用、限制访问的父目录；恢复账号应有写权限。不要把它放进备份仓库或生产共享目录。mktemp -d 在该父目录下创建一个本轮专用空目录，避免误用上次演练遗留文件。

  # 在同一个 Bash 终端执行；父目录须提前准备并核对权限
repo='/mnt/backup/restic-repo'
snapshot='REPLACE_WITH_REAL_SNAPSHOT_ID'
source_path='/srv/company-docs'
restore_parent='/srv/restore-drill'

test -d "$restore_parent" || exit 1
df -h "$restore_parent"
df -i "$restore_parent"
target=$(mktemp -d "$restore_parent/restic-XXXXXX") || exit 1
printf 'Restore target: %s\n' "$target"

restic -r "$repo" restore "$snapshot" \
  --target "$target" --include "$source_path" --dry-run --verbose=2
preview_rc=$?
printf 'Preview exit code: %s\n' "$preview_rc"
test "$preview_rc" -eq 0 || exit "$preview_rc"

预览应只列出计划恢复的目录树；核对没有其他部门目录、路径错位或覆盖生产位置。dry-run 不实际恢复文件，不能证明数据已经落盘。若本机版本不支持该参数，先停在版本适配处，不绕过预览直接恢复。

确认目标和范围后，在同一终端执行下面一块。--verify 在恢复写入后重读并验证文件数据；它不是模拟恢复；恢复后调用验证的实现可查restic v0.19.1 官方源码。--include 与快照内实际路径匹配，含通配符的路径需要按官方匹配规则单独核对。

started=$(date +%s)
restic -r "$repo" restore "$snapshot" \
  --target "$target" --include "$source_path" --verify
restore_rc=$?
finished=$(date +%s)
printf 'Restore exit code: %s; elapsed seconds: %s\n' \
  "$restore_rc" "$((finished-started))"
test "$restore_rc" -eq 0 || exit "$restore_rc"

全快照加 --include /srv/company-docs 的示例布局中，恢复文件位于 $target/srv/company-docs，不是直接位于 $target。本文不使用 SNAPSHOT_ID:/subfolder 的裁剪语法，以免混淆目录层级。restic 默认可覆盖目标里已有的文件，因此本例坚持使用全新空目录，也不使用 --delete。

退出码为零只是继续验收的必要条件。任何非零退出码、verify 错误、读写错误、空间耗尽或权限恢复告警都需保留并处理；未知退出码按失败处理。官方脚本与退出码说明是判断依据。

第四步：比较文件内容，再检查权限与实际使用

准备一份在备份时间点生成、可信且与该快照对应的 GNU sha256sum 清单，使用相对于 /srv/company-docs 的文件名；清单单独保管。下例 /srv/drill-evidence/company-docs.sha256 是示例位置，不是自动生成的现场材料。不要拿不断变化的当前生产目录做比较，也不要用恢复出来的文件生成哈希再与自己比较。

restored_root="$target/srv/company-docs"
test -d "$restored_root" || exit 1
(
  cd "$restored_root" || exit 1
  sha256sum --check --strict /srv/drill-evidence/company-docs.sha256
)
hash_rc=$?
printf 'Manifest check exit code: %s\n' "$hash_rc"
test "$hash_rc" -eq 0 || exit "$hash_rc"

  # 示例关键文件，替换为演练样本；以下只是读取元数据
stat -c '%n | %s bytes | %U:%G | %a | %y' \
  "$restored_root/policies.pdf"

--strict 使格式错误的校验行导致失败；参数见 GNU 校验工具官方说明。预期清单中每个文件均显示 OK，退出码为零。清单只证明列出的文件，未列入的文件、额外文件、空目录、链接关系和权限都要另查。用备份时的完整路径清单核对遗漏与额外内容；用关键文件的版本标识或业务日期确认选中的是正确时间点。可信清单缺失时，把结论记为“与快照数据校验一致；原始业务版本未独立核对”。

stat 不能替代全部权限验收。按备份前记录检查 UID/GID、模式位、ACL、扩展属性与符号链接；ACL 可用 getfacl 检查，命令不存在时需按发行版准备工具。恢复账号没有设置所有者的权限、目标文件系统不支持相关元数据，都可能留下可读但权限错误的文件。不要用一条全局 chmod 777 或递归改属主掩盖差异。

恢复文件先不共享到生产。使用隔离测试账号，分别验证允许访问和应被拒绝的场景，再让数据负责人用离线查看器打开关键文件、检查版本和字段。对于应用导出，使用隔离测试应用做一条只读查询；关闭邮件、支付、同步和计划任务等外部动作。若共享访问本身有问题，可参考Windows 文件共享权限验收，但不要把 Windows ACL 操作直接套入本例 Linux 命令。

图：目录恢复与验证操作示例。图内路径与快照ID为示例；run01表示需事先核对的新空目标，正文使用mktemp创建唯一目录。步骤编号是阅读分区，不表示仓库检查必须排在恢复后；正文安排在恢复前。点击高清图片查看细节，命令请从正文代码框复制。 查看高清原图

怎样判断通过，什么时候必须停止？

RPO 是可接受的数据损失时间，RTO 是恢复业务可用状态的目标时间。本例计时只覆盖 restore 命令，不等于完整 RTO；仓库接入、数据校验、权限修复和业务确认也要纳入总时长。以实际事件时间、快照时间和业务数据版本核对 RPO，不用备份任务的绿色状态代替。

建议验收单至少记录：仓库代号、restic 版本、快照完整 ID/时间/主机/路径、恢复目标、样本范围、各命令退出码与告警、哈希/清单/权限结果、业务验收人、总耗时、失败点及复验日期。日志脱敏，不保存密码。所有约定项完成后，结论限定为“本次指定快照和目录恢复通过”，不扩展成整机、全仓库或长期业务保障。

照片：Coyau / Wikimedia Commons，CC BY-SA 3.0；拍摄对象为 LaCie 500 GB 外置硬盘，2012 年图库实拍，非本文现场。仅缩放并转为 WebP，衍生照片沿用该许可。照片说明离线副本可采用物理分离介质，不证明该型号满足你的容量、寿命或安全要求，也不作为采购推荐。离线副本同样需要单独恢复验证。

FAQ

check 通过，还要执行恢复吗？

要。仓库可检查不等于文件能写到指定目标，也不等于业务能使用。实际恢复验证目标容量、文件写入、身份映射和验收流程。

--verify 会不会只检查而不写文件？

不会。它用于恢复后验证数据。只想预览范围时使用 --dry-run；两者解决的问题不同。

能否直接恢复到原来的生产目录？

本演练不这样做。原位恢复可能覆盖已有内容，操作中断还可能留下部分恢复状态。实际事故切换应有另外批准的备份、回退和业务窗口。

抽查几个文件能证明整个企业备份有效吗？

不能。报告必须说明样本、快照、目录和检查覆盖范围；数据库、整机与其他副本需要各自验收。

相关解决方案

煜企容灾备份解决方案可作为梳理现有服务器、文件备份、隔离恢复与验收范围的入口；实施内容以双方确认的环境和目标为准。

相关阅读

• 企业备份任务成功后的恢复演练
• Windows 文件共享权限验收

若要检查现有备份，可先准备一组脱敏样本、快照时间和恢复时间目标，再与煜企讨论验证范围。

返回文章列表