外观
恢复演练
完成后，你对每一类备份都亲手恢复过一次：知道步骤、知道要多久、知道恢复出来的东西真能用，并且留下了一份记录。备份能不能用，只有恢复的那一刻才知道，所以演练和备份同样重要。
演练只在测试对象上做，不碰真实数据
- 影响范围：恢复操作会覆盖或删除目标位置的内容。演练里每一次恢复的目标都必须是测试共享文件夹、一次性演练应用或一块测试盘，绝不能是真实数据。
- 前置条件：先确认备份本身存在、位置清楚；系统级演练要有一块可以随便擦的测试盘或一台虚拟机；演练之前，真实数据的备份已经是最新的。
- 怎么回退：演练出问题时，靠演练之前的那份备份回退。所以不要在没有任何备份的情况下「试试看」。
什么时候演练、记什么
| 演练 | 建议节奏 |
|---|---|
| 文件级 | 每月或每季度一次，新增备份任务后马上做一次 |
| 容器级 | 每季度一次，重大变更（换版本、换存储位置）之后做一次 |
| 系统级 | 每年一次，大版本升级之前做一次 |
每次演练记一行：
| 日期 | 类型 | 用的备份时间点 | 耗时 | 结果 | 发现的问题 | 改进 |
|---|---|---|---|---|---|---|
「耗时」很重要：它告诉你真的出事时要停机多久。
一、文件级演练
文件级是最常用的，也是最容易被忽略的一环。
准备测试数据。 新建一个演练用的共享文件夹，从电脑往里放三个文件：一个小文本、一个文档或图片、一个几百 MB 的大文件。在 OMV 的 shell 里或电脑上计算校验值并记下来：
shsha256sum <文件>制造「事故」。 删掉其中一个文件，再修改另一个文件的内容。
恢复到一个新位置。 按备份来源选一种，目标不要是原目录：
- rsync 备份或 USB 备份盘：从目标共享文件夹或备份盘里直接复制回来。不要为了演练用 USB 备份的「取回」模式去覆盖整个共享文件夹。
- Btrfs 快照：Windows 的「以前的版本」、把快照「分享」成共享文件夹，或在 shell 里
cp -a，见共享文件夹快照。 - borg、restic：用插件里的恢复功能，恢复到另一个目录，步骤见各自的插件文章。
校验。 对恢复出来的文件再算一次
sha256sum，和第 1 步的值逐个对比，并且打开文件看看。被你「改过」的那个文件，应该能取回改之前的版本。这要求备份有历史，只有镜像的话取不回，这正好暴露了镜像的局限。记录耗时和遇到的问题。
清理：删除演练用的共享文件夹和多余的快照。
二、容器级演练
目标是证明：应用被删掉之后，能从 Compose 插件的备份把 compose 文件和数据一起恢复，应用起来后数据还在。
不要用真实应用演练。 恢复会覆盖现有的 compose 文件和数据。准备一个一次性的演练应用。
- 用
服务 → Compose → 文件（Services → Compose → Files）的 从模板添加（Add from Example），部署一个轻量、会往数据目录写文件的应用，步骤见部署第一个应用。启动后在应用里创建一点数据，比如一条笔记。 - 打开
服务 → Compose → 计划（Schedule），创建一条备份任务：过滤（Filter）里只填演练应用的名字，动作类型选维护（Maintenance）并勾选备份。保存，应用，选中任务点 运行（Run）。备份会先停掉容器，备份完再启动。 - 打开
服务 → Compose → 恢复（Restore），确认出现这个应用的备份行，有备份时间。 - 制造「事故」：停止并删除演练应用，再删掉它的数据目录。
- 在 恢复 页选中那条备份，点 恢复。它会停掉受影响的容器，还原 compose 文件和数据，再启动。
- 打开应用，看之前创建的数据是否还在。
容器级演练最容易发现的两个问题：
- 数据卷太大没被备份。 Compose 备份默认只备份不大于 1 GB 的卷（
服务 → Compose → 设置（Services → Compose → Settings）里备份部分的 最大尺寸，0 表示不限制），更大的卷会被跳过。恢复之后应用起来了但数据是空的，就是这个原因。 - 数据库类应用热备份不一致。 默认会先停容器再备份；如果勾选了跳过停止，运行中的数据库文件可能不一致。
详见 更新与备份容器。
三、系统级演练
目标是证明：系统盘备份能在一块空盘上还原，并且还原出来的系统能启动、能登录、配置还在。流程依据 备份系统盘，建议先读完它。
本站没有在实机上走完整套系统恢复
插件作者的文档和脚本是依据，没有人替你验证过你的机器。所以这一步更要用测试盘做，并且按下面的隔离要求做。
隔离是第一要求
还原出来的系统和生产系统长得一模一样：同样的主机名、同样的静态 IP、同样的文件系统 UUID、同样的计划任务和密钥。如果同时接着生产系统盘或数据盘、同时联网，会出现 IP 冲突、两块盘 UUID 重复导致启动混乱，甚至让这个克隆的系统去执行计划备份。所以：
- 最好用另一台机器或虚拟机做，不要用生产机。
- 必须用同一台机器时：关机，拔掉原系统盘和所有数据盘，只留测试盘，并且不要接网线，演练结束后再恢复原样。
- 绝不要让两块 UUID 相同的系统盘同时接在一台机器上。
虚拟机演练测不到真实硬件的问题（引导方式、网卡名），但足以验证备份文件和恢复流程。
步骤
准备测试盘（或虚拟机的空虚拟磁盘），不小于原系统盘。准备好救援系统（SystemRescue）启动盘，和能读到备份的方式，比如 Recovery USB 或把备份复制到可挂载的位置。
用救援系统启动，找到备份目录。先预演：
sh./omv-restore-helper --dry-run auto预演没问题，再在救援系统里运行
./omv-restore-helper auto，选测试盘作为目标，手工输入设备路径确认。目标选错会覆盖那块盘上的数据，按容量、型号核对，不确定就中止。恢复完成，记下耗时，拔掉救援盘，从测试盘启动。
验证，下表逐项打钩。不要在这个克隆系统里点应用任何改动，也不要联网。
演练结束后关机，擦除或保留测试盘，恢复原来的硬件连接。
验证清单
| 检查项 | 预期 |
|---|---|
| 能启动到登录界面 | 是 |
| 能登录 Web 界面 | 是，账号和密码是备份时的 |
| 版本和插件 | 和备份时一致，系统 → 插件（System → Plugins）里装着的插件都在 |
| 共享、服务、用户、计划任务的配置 | 都在 |
| 数据盘上的文件系统 | 显示为丢失（Missing），因为你没接数据盘，这是预期的，不是失败 |
| 时间和时区 | 正确，不对则先调时间 |
常见失败点
| 现象 | 原因 | 办法 |
|---|---|---|
| 找不到备份文件 | 备份所在的盘没挂载，或 Recovery USB 的文件系统救援系统读不了 | 换 ext4 或确认救援系统支持 exfat |
| 恢复到一半报空间不足 | 目标盘比源盘小 | 换一块不小于源盘的盘 |
| 设备名不对 | NVMe、SD 的分区名带 p，sda 与 nvme0n1 混淆 | 用 lsblk 核对，使用恢复助手的 auto 模式 |
| 恢复后无法启动 | 引导方式（BIOS 与 UEFI）不一致，或用 fsarchiver、borg、rsync 恢复后没装引导 | 按 RESTORE-README.txt 重装 GRUB |
| 加密备份打不开 | 忘了密码，或密码只存在 NAS 里 | 密码必须保存在别处，见异地与云端备份 |
| 换了硬件后没有网络 | 网卡名变了 | 用 omv-firstaid 重配，见改坏网络后怎么救 |
| 容器起来了但数据是空的 | 卷超过备份的最大尺寸被跳过 | 调大上限，或另行备份大卷 |
| 备份太旧 | 备份任务早已失败，没人看通知 | 配好邮件通知，检查最近一次成功时间 |
检查结果
每种演练都达到这个标准才算通过：
- 恢复出来的东西打开过、用过，不只是「命令没报错」。
- 耗时已经记下，你知道真出事时要停机多久。
- 所有失败点要么已经解决，要么写进了改进列。
- 恢复所需的一切材料（密码、密钥、救援盘、备份位置）你能在 NAS 不可用的时候拿到。
常见问题
演练太麻烦，能只验证备份文件完整吗？ 可以做完整性检查，比如 zstd -t、borg 或 restic 的检查功能，但它只能说明文件没坏，不能说明你会恢复，也不能说明恢复出来的东西能用。两者都要。
文件级演练多久做一次？ 至少每季度一次。这是最便宜、也最容易发现问题的一种。
我没有备用盘和备用机器怎么办？ 用虚拟机做系统级演练；文件级和容器级用测试共享文件夹和一次性应用做。
参考资料
- 插件作者的恢复文档：openmediavault-backup。
- Compose 插件的备份与恢复依据 omv-extras wiki Compose 插件手册和插件源码。