备份容器还是容器里的文件？按恢复形态来定

你可以把一个加密容器整体当作一个对象备份，也可以挂载它并备份里面的文件。两者都能顺利穿过 VPN，相似之处也仅止于此。它们恢复的东西不同，依赖的密钥不同，占用的存储不同，而且在有人需要取回数据时失败的方式也不同。先选恢复对象，再选传输方式，最后选存储副本的加密方式。下面的清单按这个顺序展开，因为几乎每一场备份之争，本质上都是关于这三件事里哪一件先定下来的分歧。

两个对象，两种恢复形态

镜像级备份恢复的是一个容器：拿回的是加密卷，要打开它仍然需要它的恢复密钥材料。文件级备份恢复的是文件与目录树，保护它们的是备份仓库自身的加密，而不是原容器的加密。把数据平铺复制到远端文件夹是第三种情况，它继承的是那个文件夹碰巧拥有的保护。

中间那一行最容易被误读。它完全可以是好设计：备份程序在本地读取明文，写出经过加密和认证的仓库。此时安全性取决于那个程序和它的凭据，而不是原容器的密码，两者不该被描述成同一种控制。

检查 1：恢复必须重建什么？

把问题问成恢复，而不是备份。如果需求是“把这套服务在另一台主机上跑起来”，镜像加上它的恢复材料就是连贯的答案。如果需求是“把三月的财务表取回来”，为了抽出一个文件而恢复一个数十吉字节的镜像，是昂贵的答案。两者都是正当的恢复，它们也不是可以互换的预算。只写其中一种的计划，迟早会被另一种检验。

把恢复目标写进计划：整个卷、一棵目录树，还是单个文件。然后记下哪些元数据必须一起走，因为属主、权限、扩展属性和时间戳都属于文件级恢复的一部分，而在测试时看起来够用的复制式流程里，它们经常被丢掉。

还要决定由谁执行恢复。任何操作员都能挂载的文件级仓库，与需要密钥持有人到场的镜像，是两种不同的访问模型，谁都不自动更好。重要的是这个选择是有意的，并且写了下来。

检查 2：存储副本受什么保护？

VPN 保护的只是一段传输。传输结束之后，它对存储副本什么也没说，而“它是走隧道过去的”并不是关于备份运营方能否读取你数据的陈述。如果远端由别人运营，问题在于他们能读到什么，而不是链路是否加密。

对镜像来说，这意味着把容器的密钥材料与镜像本身分开保护。丢了头部就丢了整个卷，所以要把头部备份到镜像不在的地方：

cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20

对文件级仓库来说，要确认工具在内容与元数据离开主机之前就完成加密与认证，并弄清密钥在谁手里。Restic 的设计文档明确指出，它假设源主机是可信的，并且加密并不能阻止拥有存储访问权的人删除备份。这两条告诫都重要：仓库可以是机密的，同时照样被毁掉。

检查 3：副本是一致的吗？

对一个正在变化的文件系统取到的备份，只是一份副本，不是恢复点。对镜像来说，要用卷工具支持的方式取得稳定的快照，通常意味着快照操作或卸载，而不是在大文件变化时去读它：

lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonly

对挂载的文件来说，活跃数据库和其他需要协调的数据要走应用支持的、能保证一致性的流程。文件系统级副本与应用一致恢复点是两种不同的描述，差别只有在你试图从恢复出来的副本启动应用时才会显现。

把恢复材料放在独立的受保护路径上。丢掉原机器，绝不该同时丢掉唯一能打开它备份的凭据，而当密钥文件就住在被备份的那个卷上时，发生的正是这件事。要刻意测试这种分离：在一台从未见过原机的主机上，只用计划里声明可用的东西做恢复。

检查 4：变化检测对这个对象成立吗？

加密容器在大多数传输工具眼里就是一个巨大而不透明的文件，所以一次明文的微小改动，可能造成大范围重读或整体重传，具体取决于工具和格式。restic 文档里描述的可变长度分块与去重可以减轻这一点，但那是那个工具的特性，不是加密容器的通性。

测量，而不是假设。在一次微小无害的改动之后，比较第一次与第二次运行，记录传输字节数和耗时。试验期间保留一份已知良好的备份，免得某次测试耗掉你唯一的恢复点。

最后用唯一真正算数的测试收尾：在没有原机的情况下恢复。打开一个恢复出来的容器，或者连同元数据恢复选定的文件，确认应用或用户能用上结果。一次快速、加密良好的传输如果答不上这个测试，那只是数据的副本，不是它的备份。