Answers:
使用校验和的最有效方法是使计算机完成所有操作。使用诸如ZFS之类的文件系统，该文件系统在写入数据时对所有数据进行校验和（实际上，它使用比校验和强的哈希值），并在每次读取数据时对其进行验证。当然，缺点是ZFS不知道何时删除或覆盖文件是错误的以及何时是正常操作，但是因为ZFS对所有内容都使用写时复制语义，因此可以使用其快照功能来减轻风险。
ZFS还可以通过使用您设置的任何冗余（raid5样式的奇偶校验，驱动器镜像或重复副本）自动恢复未通过哈希检查的数据（将copys = N属性添加到任何ZFS文件系统中，它将存储N个副本您写入的任何数据）。它还将哈希存储在Merkle树中，其中文件的哈希值取决于块的哈希值，目录项的哈希值取决于其包含的文件和目录的哈希值，文件系统的哈希值取决于在根目录的哈希值上，等等。
无论最终采用哪种解决方案，您都将发现该过程不受磁盘速度的限制，而不受CPU速度的限制。
另外，不要忘记考虑磁盘的BER。毕竟，它们仅仅是旋转的铁锈板。消费级驱动器的错误率是：每读取10 ^ 14位，就会错误读取1个错误位，这相当于您读取的每11 TB字节中有1位错误。如果您有一个11 TB的数据集，并且计算了其中每个文件的哈希，则将错误地计算出其中一个校验和，并永久损坏了数据集中其中一个文件的一个块。但是，ZFS知道它写入池中每个磁盘的每个块的哈希，因此知道哪个块丢失了。然后，它可以使用池中的冗余（奇偶校验，镜像或额外副本）以正确的值重写该块中的数据。
Ben在评论中提出了一个很好的观点。ZFS不会向用户公开其计算的任何哈希值，因此进入或离开ZFS系统的数据应带有散列。我喜欢Internet存档使用该存档中每个项目随附的xml文件执行此操作的方式。例如，请参阅https://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xml。
这个答案是@ lechlukasz和@ db48x的答案的结合，还结合了评论中提到的一些观点以及我自己的一些想法。
前进的简单路径是文件系统和元数据分离的组合方法。
通过使用实时数据散列和验证的文件系统，例如ZFS或Btrfs（请注意，尽管已经取得了很大的进步，但Btrfs目前尚不适合生产使用），因此您可以合理地使用请确保如果可以从磁盘上读取数据而不会出现操作系统错误，则以文件系统预期的方式将读取的数据写入磁盘。通过运行定期的“ scrub”操作，将根据文件系统应有的想法读取并验证所有数据。
但是，这只能防止磁盘损坏（无法读取的块，完全的硬件写入错误，无效的写操作，这些写操作直接破坏了块设备上的部分数据，等等）。它不能防止软件错误，错误的用户操作或通过预期的操作系统功能运行以处理文件的恶意软件，前提是这些工具没有此类错误。
为了防止后者，您需要另一层保护。从用户应用程序的角度来看，对数据进行校验和或哈希处理将有助于防范许多上述风险，但需要单独执行（作为软件中的内置过程操作或完全独立的过程）。
使用当今的硬件以及用于存储大量数据的实用工具（与固态磁盘/ SSD相比，旋转拼盘硬盘），即使是诸如SHA1之类的复杂哈希算法也将在很大程度上受到I / O限制-即速度散列数据的时间将取决于存储系统的读取速度，而不是计算机处理器计算散列的能力。我做过一个实验，在2012年的中级家用PC上运行了大约150 GB数据的用户空间MD5哈希过程，并且在几乎不中断磁盘运行40分钟后就完成了它。将这些数字放大100倍，您将在大约三天的时间内在相同的硬件上获得15 TB集合的MD5哈希值。通过增加读取传输速率（可以轻松实现，例如例如，RAID 0是无冗余的条带化，通常可用于实现更高的读/写性能，可能与形成RAID 10的 RAID 1结合使用，对于相同数量的数据，可以缩短完成时间。
通过将两者结合起来，您可以兼得两全：文件系统可确保您在读取文件时收到的内容是实际写入的内容，并且单独的固定性检查过程可以遍及整个集合，从而确保数据存储的内容仍与提取到存档中的内容匹配。两者之间的任何不一致（文件系统说文件没问题，固定性检查说不是）都将指示文件已在档案的预期操作模式之外但在操作系统工具内部进行了修改，从而提示从辅助设备还原复制（备份）。固定性检查因此可以在更长的时间间隔内运行，这对于非常大的存档来说是必不可少的，但是如果读取成功，仍然可以保证硬件上的任何在线访问都不会受到破坏。原则上，归档软件可以依靠文件系统将不一致报告为读取错误，并在用户处理文件时在后台执行单独的固定性检查，并显示适当的消息，以表明文件与摄取的文件不匹配进入档案。使用散列文件系统，这样的方案将对感知性能的影响最小，同时仍可确保内容正确。
我已经仔细研究了答案，尽管我喜欢依靠ZFS处理数据层错误的想法，但仍然存在文件被错误或恶意更改的问题。在这种情况下，ZFS不会为您提供保护，就像其他人提到的那样，ZFS不会为您提供用户可见的“哈希”来存储其他地方进行外部验证。
有一个名为TripWire的Linux应用程序，已广泛用于监视系统可执行文件，以验证攻击后它们没有被更改。该项目显然已被放弃，但是AIDE (Advanced Intrusion Detection Environment)在ServerFault上推荐了一个名为的新项目：
/server/62539/tripwire-and-alternatives
安装后，它将每隔x分钟运行一次，用户可配置，并且它将检查您指定的所有文件夹中文件的更改。它需要运行一次以计算所有文件哈希，然后在此之后，针对当前文件检查所有哈希，并确保它们仍然相同。您可以指定要使用的哈希类型或哈希组合（我不建议使用比SHA-256弱的名称），要使用的文件属性（内容，大小，修改的时间戳记等），检查的频率，如何/在何处存储哈希数据库等
有些人可能会认为这种过大的杀伤力，但是根据OP的要求，这可能会使他更加安心，因为他存储的数据在特定时间点后将保持不变。
澳大利亚国家档案馆开发了[Checksum Checker]（http://checksumchecker.sourceforge.net/），该文件可在GPLv3下免费获得。
它从数据库读取校验和和算法，然后重新计算文件的校验和，比较两个值并报告是否存在错误。它支持MD5，SHA1，SHA2，SHA256和SHA512算法。
其数字存储库[DPR]（http://dpr.sourceforge.net/）中的其他软件会生成初始校验和（以及进行所有其他处理活动）