☰

简介和一些术语

tag-icon • tag-icon backup validation verification
简介和一些术语

简介和一些术语

向“超级用户”社区问好！

正如标题所暗示的，我的问题是关于对基于映像的备份进行完整（完整）验证和确认的过程。但首先，我要说一句：我想，“验证”和“确认”这两个术语的使用存在一些混淆，因为同一过程（例如，在 VM 中测试创建的映像）在不同资源上被称为“验证”和“确认”。这就是为什么在这里（在评论或答案中）澄清一下会很好。但不必深入讨论这些术语细节：我在这里问的是如何检查是否复制了正确的数据（即完整地，精确到每一个比特）。而“验证与确认”（为简单起见，下文中简称为“V&V”）我在这里指的是这样的检查

一些假设

而且因为备份是一个相当大的分支（领域），我认为应该引入更多假设：

  1. 让我们在这里考虑操作系统备份的问题（当然，包括正常启动所需的所有系统分区和用户文件），因为我认为这种类型的备份是最普遍的备份任务之一（其他备份情况可能被视为只是操作系统备份的一种特殊且更简单的情况）
  2. 此外，为了一般性，让我们回顾一下所有最常见的存储类型（作为备份的源驱动器，即安装了操作系统的驱动器）：因此，它是 SSD 和 HDD（CMR 和 SMR）
  3. 让我们考虑没有任何故障和错误的硬件
  4. 让我们忽略存储备份的问题，并假设备份软件写入的数据被准确存储（没有任何不必要的修改），因此这里只关注 V&V 阶段
  5. 至于操作系统和文件系统，我想，对于一个或另一个操作系统或文件系统，过程不会有太大差异。我的问题主要侧重于 Windows 和 NTFS（只是因为我比其他人更了解和使用这些系统），但重点关注任何操作系统的答案都很好

回顾最常建议的备份 V&V 策略

对于备份 V&V，通常建议采用以下策略（在不同的资源中：软件文档、文章、博客等），但在我看来，这些策略并不完整（我会解释为什么我这么认为）：

  1. 从创建的映像启动：通过将映像附加到虚拟机或将备份（提取映像）恢复到第二个磁盘并选择它作为启动驱动器。此方法是统计方法：它基于进行一些选择（例如，从总共 5,000,000 个文件中选择系统启动所需的 100,000 个文件），并且如果此选择中的文件一致（这由操作系统的正常启动和运行确认），则可以估计（“推断”）所有其他文件也一致。通过启动已安装的软件，可以以类似的方式检查更多文件。但是，假设标准 Windows“文档”目录中有数百个文件：其中一个文件的损坏根本无法通过此方法发现。这同样适用于不直接参与启动且通常很少被操作系统访问的系统文件（例如一些 *.dll 文件）

  2. 直接“并排”比较驱动器及其映像内容。例如，使用 Beyond Compare、WinDIFF、WinMerge 等软件。但这些软件在文件系统（文件和文件夹）级别上运行，我认为这不是最好的方法：即使考虑离线操作系统，也需要安装文件系统（在另一个操作系统中）（因为该软件适用于“带字母的东西”，如“C:”​​、“H:”等），因此：

    • 至少，像 MSR（Microsoft 保留分区）这样的分区的备份无法使用此方法进行验证和确认（因为它们根本不包含任何可挂载的文件系统）
    • Windows（我认为其他操作系统也是如此）可以执行（并且通常执行得相当主动）对已挂载的文件系统（例如，Windows，至少在System Volume Information文件夹中）的写入，并且与动态更改的对象相比 ─ 当然不是一个好主意
    • 此外，NTFS 权限可以在比较期间阻止对系统文件的访问。这里不确定，因为我对 NTFS 权限系统不太熟悉，但检查了最近的“Windows To Go”安装，确实，至少R:\Windows\CSC\v2.0.6\pq访问被阻止了。但这一点可能被视为未经证实的，推测（当然，在答案或评论中澄清会很好）
    • 还有一点“补充”：文件系统挂载在安全性方面可能不太好。例如，在主系统“下”复制可能不安全的系统时。但这里可以使用所谓的“实时操作系统”。或者虚拟机（但我还没有为此测试过虚拟机）

  3. 运行“内部”验证功能。这非常方便，但这种方法不会揭示备份软件本身或“数据提供商”（例如 VSS）中的错误设置或错误，因此某些数据可能不包含在备份中。换句话说，这种方法检查部分数据已正确传输，大致如下：

    块 10 具有3500BA09D0538297440CA620C9DD46BF磁盘上的哈希值和3500BA09D0538297440CA620C9DD46BF创建的图像中的哈希值 => 已正确复制；
    块 500 具有FAE8A9257E154175DA4193DBF6552EF6磁盘上的哈希值和FAE8A9257E154175DA4193DBF6552EF6创建的图像中的哈希值 => 已正确复制；
    块 2500 具有7F138A09169B250E9DCB378140907378磁盘上的哈希值和7F138A09169B250E9DCB378140907378创建的图像中的哈希值 => 已正确复制；
    …

    但没有检查复制了正确的数据：第 10 号、第 500 号和第 2500 号区块正是我们感兴趣的

  4. 所有上述方法的组合

问题本身

因此，主要思想是找出（或创建）一种更强大（更强大）的检查过程（技术），可以替代所有列出的方法，或者当然可以作为它们的补充使用。它也可以被视为检查备份软件本身的方法。这种技术的速度和易用性可能不是那么好（它们不是优先考虑的）。我想，这种完整的检查方法应该是“基于哈希的”，但这只是一个假设（这就是我的问题在这里的原因）

附加评论

以下是我对如何实现这一点的想法（3 种方法，按 V&V 的便利性排序）。文本相当长，但它更像是一个附加评论，有点像我自己的小研究，我只是为了以防万一而加入的。所以，没有必要阅读它来理解主要问题（因为主要问题在上面已经完整描述了）。我在这里介绍两个系统，分别表示为系统 1 和系统 2：系统 1 – 应该复制的操作系统，系统 2 – 执行备份过程的操作系统。所以，这是我的附加评论

方法 1

直接从系统 1 制作映像。这不是验证方面的最佳选择，因为在创建映像后，源磁盘上的文件将被此系统修改（日志、临时文件等）。是的，这里最好不要与驱动器本身上的文件进行比较，而是打开（安装）VSS 快照进行比较。但上面第 2 点中列出的此类比较的所有问题和挑战也适用于此

还有一件事。通常，备份软件也不会复制“动态”文件本身，而是复制 VSS 快照中的数据。但这里只对 VSS 汇编的数据与备份软件从 VSS 复制到映像文件中的数据进行比较。而且，我认为 VSS 中可能存在一些错误，因此并非所有数据都会“传输”到 VSS 快照，然后从那里传输到备份软件。此比较确认复制“VSS 快照 -> 映像文件”没有错误，但无法确认整个复制过程“磁盘上的实际数据 -> VSS 快照 -> 映像文件”是否正确完成。所以，是的，上面第 3 点的主要思想，但描述得更详细

方法 2

关闭系统 1，启动系统 2，并从中创建映像（系统 1 的映像，现在处于离线状态）。离线系统可以看作是一堆“静态”文件和文件夹（参考)，因此相当复杂的在线操作系统备份过程简化为正确复制所有这些“脱机”文件，这是一项简单得多的任务。我认为，现在复制（到映像）的数据直接基于 $MFT 文件（和其他 NTFS 元文件）。比 VSS 复制好得多，因为现在删除了一层（这增加了复杂性，并且可能增加了错误），但仍然可能出现一些错误（例如，由于 NTFS 元文件损坏；例如，这里在“如何验证磁盘映像或磁盘克隆？”部分）。然后打开原始磁盘及其映像并进行比较。例如，如上文第 2 点所述。或者使用其他方法：

  • 通过计算（并比较）磁盘和映像（例如，使用 7-Zip）上相应目录（例如，“Windows”目录）的哈希值（例如，SHA256）。但是，如上所述：权限可能会阻止访问。此外，符号链接（例如，“Documents and Settings”，它保留在系统驱动器的根目录中并指向C:\Users；大概是为了向后兼容）增加了哈希的复杂性。此外，元数据也应该以某种方式包含在生成的哈希值中
  • 通过比较相应文件夹的大小以及其中的文件和子文件夹的数量。不太可靠的比较方法
  • 仅通过“视觉”比较磁盘和映像的内容（例如使用文件管理器）。也不是很可靠。而且这是一种半手动且不太有效的方法，但这也不是最好的方法，正如上文第 2 点所述。一般来说：在文件和文件夹级别比较内容看起来不太方便和高效

方法 3

关闭系统 1，启动系统 2，并从中创建（离线系统 1 的）映像。但之后，计算的哈希值不是单个文件和文件夹，而是整个磁盘（磁盘内容）及其映像（映像内容）。磁盘哈希计算可以在不挂载文件系统的情况下完成（例如，在 HxD 中）。哈希匹配将提供 100% 的保证（可以忽略哈希冲突，特别是在 SHA256、SHA512 或类似算法的情况下，冲突概率极低；此外，甚至不能使用像 MD5 这样的“强”哈希，因为我们期望内容相同，并且至少不会被故意修改），原始（物理）磁盘和映像中存储的内容完全相同。但似乎甚至可以对未挂载的卷进行一些写入（参考编号1，参考编号2，参考号3)，因此这里应该附加一个所谓的“写阻止程序”来完全阻止磁盘写入。但是好吧，让我们允许一些写入，因为它们应该相当小（似乎只执行“服务”操作，即没有写入 GB 的数据）。但在这种情况下，一次对整个磁盘进行哈希处理并不是最好的策略：因为哈希函数“在设计上”是极其非线性的[^1]。可以通过将数据拆分为“块”或“块”（从而降低强度，但同样，这不是真正的加密情况）来减少（甚至完全消除）哈希的这种（在我们的情况下不想要的）属性，例如每个 1GiB 或 10 000 个块。例如，这种方法在Atola 硬件软件综合体，他们称之为“分段哈希”。因此，应用“分段哈希”的结果如下：

Blocks 0-10 000, SHA256: 249CB3CB46FD875196E7ED4A8736271A64FF2D8132357222A283BE53E7232ED3
Blocks 10 001-20 000, SHA256: 92F24FED2BA2927173AAD58981F6E0643C6B89815B117E8A7C4A0988AC918170
…

初始驱动器及其映像都是如此。如果出现不匹配，则它们将被“定位”到某个范围（例如，块 210 001 – 220 000）。之后可以减少“哈希范围”（例如，减少到 100 个块），并且可以更精确地检测差异区域。然后可以进行直接分析，以查明这种差异是由于映像过程中的错误还是由于对卷的少量“服务”写入而发生的。但在这里直接（“逐位”）比较可能更为理想（例如，讨论这里）

此外，备份软件通常不会创建 RAW 磁盘映像（其中包含全部复制可访问磁盘空间上的数据（包括未分配或标记为可用空间），但仅复制已分配的空间（即文件系统占用的空间）以减小映像大小。这非常方便。但这可能是错误哈希不匹配的来源，因为：

  1. 对于没有 TRIM 的存储设备（通常是传统的 CMR 硬盘），源磁盘上未分配空间中的数据（在这种“线性”哈希中）将“贡献”到哈希中，而我认为在图像中相应的块中将只是零
  2. 对于带有 TRIM 的存储设备（通常是 SSD 和 SMR 硬盘），事情（大概）会变得更容易，因为在这种情况下，未分配（至少由于删除）的空间将在原始磁盘和其映像上都用零填充。但我认为，这里也可能存在一些特殊情况（例如，覆盖文件等），这些特殊情况可能会生成不匹配的哈希值

当然，可以通过使用“dd”等软件制作 RAW 图像来消除这种特殊性。但“dd”不如备份软件方便（例如，不提供增量或差异图像）

并且看起来通过散列验证会产生很多不匹配的情况，并且应该彻底检查每个这样的情况以找出这种不匹配的根源：

  • 这是否是数据复制中的真正错误 - 这是否只是“技术写入”（低级操作系统和文件系统操作），只会产生微不足道的更改，不会影响“主要”数据
  • 无论是镜像中的优化（由备份软件完成的）还是由于这些优化而导致的磁盘和镜像结构差异

这就是为什么需要进一步发展（这种方法）

结论

嗯，是的，这就是我的问题、我的想法和观点。谢谢你的关注。当然，期待听到意见和答案

[^1]：哈希“反映”的只是数据中存在差异，并没有说明修改的原因、地点和数量。因此，哈希可以被完全改变，只需修改 1 位，也可以通过修改 5GiB 数据，也可以通过修改磁盘上的全部数据

相关内容