SFV/CRC32 校验和是否足够好且足够快以检查常见的备份文件？答案

【问题标题】：SFV/CRC32 checksum good and fast enough to check for common backup files?SFV/CRC32 校验和是否足够好且足够快以检查常见的备份文件？
【发布时间】：2015-12-24 18:52:37
【问题描述】：

我有 3 TB、超过 300,000 个各种大小的参考文件（每个文件 20、30、40、200 兆），我通常会定期备份它们（不压缩）。几个月前，我丢失了一些文件，可能是由于数据退化（因为我在没有通知的情况下“备份”了损坏的文件）。

我不关心安全性，所以不需要 MD5、SHA 等。我只是想确保我正在复制的文件是好的（相同的位和字节）并验证备份是否完好无损几个月后再次进行备份。

因此，我的需求是基本的，因为文件不是很重要并且不需要安全性（没有敏感信息）。我的疑问：格式/方法“SFV CRC/32”是否适合我的需要？还有比这更好更快的东西吗？我正在使用 ExactFile 程序。

是否有任何校验和比 SFV/CRC32 更快但没有缺陷？我尝试使用 MD5，但速度很慢，而且由于我不需要数据安全，我更喜欢 SFV/CRC32。尽管如此，这还是很痛苦，因为有超过 300,000 个文件并且需要数小时才能对所有文件进行校验和，即使使用 CPU 至强 8 核 HT 和快速硬盘也是如此。

从数据完整性的角度来看，将所有文件合并到一个 .ZIP 或 .RAR 中而不是让它们“松散”在文件夹和文件中会有一些优势吗？

一些提示？

谢谢！

【问题讨论】：

标签： backup checksum crc32 integrity

【解决方案1】：

如果您可以量化“几个月前，我丢失了一些文件”中的“少数”和“一些”（其中“少数”将被视为替换为“每隔几个”以获得速率），那么您可以计算误报的概率。但是，从这些话中，我会说，是的，32 位 CRC 应该适合您的应用程序。

至于速度，如果您使用的是最新的 Intel 处理器，您可能有一个 CRC-32C 指令，它可以使计算速度提高大约 15 倍。（有关某些代码，请参阅 this answer。）通过在多个内核上运行它可以更快。如果做得好，你应该受到 I/O 的限制，而不是计算。

在这种情况下，将它们捆绑在 zip 或 rar 中没有任何好处。事实上，如果该文件的损坏导致您丢失所有内容，情况可能会更糟。

【讨论】：

马克·阿德勒，感谢您的澄清。自 1997 年以来，我一直在这里保存文件，并且一直在从 HDD 复制到 HDD。所以总是想用校验和来验证一切正常。直到今天，我从未遭受过重大损失（只有几个损坏的文件），但我每天都对备份更加偏执。我很快学到的一件事是永远不要压缩文件。关于“误报”，这是否意味着即使校验和正确，某些文件也可能已损坏？再次感谢您的澄清。
是的，误报是指文件中存在正确的错误以将其 CRC 恢复为原始值。如果文件损坏，在这种情况下偶然发生的概率非常小，约为 2^(-32)。由于在您的情况下被损坏的文件数量似乎非常少，因此该概率应该是可以接受的。

【解决方案2】：

如果您没有获得每个内核每秒至少 250 MB 的吞吐量，那么您可能受到 I/O 或内存速度的限制。 CRC32 和 MD5 的原始散列速度比这更高，即使在已有数十年历史的硬件上，假设一个非糟糕的合理优化实现。

查看Crypto++ benchmark，其中还包含大量其他哈希算法。

Castagnoli CRC32 比标准 CRC32 或 MD5 更快，因为较新的 CPU 有专门的指令；使用该指令和大量支持代码（用于并行散列三个流，将部分结果与一些线性代数拼接在一起，等等），您可以将散列加速到大约 1 个周期/dword。由于特殊的 AES 指令，基于 AES 的哈希值在最近的 CPU 上也快如闪电。

但是，最终哈希函数等待读取数据的速度有多快并不重要；尤其是在多核机器上，您几乎总是在这样的应用程序中受到 I/O 限制，除非您被小型缓存和深内存缓存层次结构的延迟所破坏。

我会坚持使用不比 CRC32 慢且普遍可用的 MD5，即使在最古老的机器上，几乎在所有发明的编程系统/语言中也是如此。不要将其视为“加密安全哈希”（现在不是，不再是），而是某种 CRC128，它与 CRC32 一样快，但需要一些 2^64 哈希才能发生冲突，而不是像 CRC32 那样只有几万个。

如果您想滚动一些自定义代码，那么 CRC 确实有一些优点：文件的 CRC 可以通过将子块的 CRC 与一些线性代数相结合来计算。使用像 MD5 这样的一般哈希是不可能的（但您总是可以并行处理多个文件）。

有大量现成的程序可以快速计算文件和目录的 MD5 哈希值。我推荐 md5sum + 表兄弟的“深度”版本：md5deep and hashdeep，您可以找到 on SourceForge 和 on GitHub。

【讨论】：

【解决方案3】：

Darth Gizka，感谢您的提示。现在我正在使用你指出的 md5deep 64 。这很好。我以前用的 ExactFile，2010 年就停止更新了，现在还是 32 位（没有 64 位版本）。我对两者进行了快速比较。 ExactFile 创建 MD5 摘要的速度更快。但是比较摘要，md5deep64 要快得多。

正如你所说，我的问题是硬盘驱动器。对于备份和存储，我使用三个 Seagate，每个 2 TB（7200rpm 64 兆高速缓存）。使用 SSD 的过程会快得多，但对于 TB 级的文件，使用 SSD 非常困难。

几天前，我在部分档案中做了这个程序：1 tera（大约 170,000 个文件）。 ExactFile 花了大约六个小时来创建摘要 SFV / CRC32。我使用了我的一台较新的机器，配备了 i7 4770k（嵌入了 CRC32 指令，8 个内核 - 四个真实和四个虚拟，MB Gygabyte Z87X-UD4H，16 RAM）。

在整个文件计算过程中，CPU 内核几乎无法使用（3% 到 4%，最大 20%）。硬盘已被 100% 使用，但是，仅达到了他的速度能力的一小部分（sata 3），大部分时间为 70 MB / s，有时会下降到 30 MB / s，具体取决于正在计算的文件数量和防病毒在后台（我后来禁用了，因为我在复制大量文件时经常这样做）。

现在我正在测试一个使用二进制文件比较的复制程序。无论如何，我将继续使用 md5 摘要。感谢您提供信息，欢迎提供任何提示。

【讨论】：