是否有专门用于恢复数据损坏的单个文件（存档）的文件校验和？可以使用哈希之类的简单方法恢复文件
我正在尝试通过压缩和标注日期来存档一些家庭和企业文件（不是媒体文件）的备份。目前最大的存档大约有 250GB。创建存档后，我对其进行了 MD5 校验，将存档传输到另一个驱动器，然后使用 MD5 验证文件是否正确传输，并将 MD5 哈希值与存档一起存储以供将来验证。我计划每年存档这些备份 1-2 次，并在预算允许的情况下将它们存储在 HDD 和磁带上。
当前存档格式为“Zipx”，设置最高。
鉴于目前每年约 1-2 TB 的信息量，我预见到将出现某种数据损坏问题；尤其是考虑到这些文件位于消费者驱动器上。此外，备份最终会在驱动器之间、磁带之间以及磁带之间传输回来，因此最初的 250GB 档案实际上可能包含数 TB 的写入和读取数据，这增加了数据损坏的风险。每次传输后验证 MD5 会增加大量时间，因为 MD5 检查受到 I/O 限制；对 250GB 档案进行 MD5 检查需要很长时间，乘以所有档案，MD5 必然不会按需要进行检查。
因此假设如下：
- 数据将被破坏
- 我们直到事后才会知道这一点。
- 由于预算限制和缺乏“关键任务”，我们没有完全相同的备份档案的多个副本，只有不同迭代的备份。
- 我们希望尽量减少备份副本数量，同时防止数据损坏。
- 如果档案中的一个或两个文件确实损坏了，我们在尝试恢复时丢失了数据；生活仍会继续。这不是一件关键任务。
- 这些档案是二次备份，希望在十年或更短的时间内不会使用超过几次。实时备份未压缩。
基于这些假设，我们如何防止数据损坏。
存储 MD5 哈希值只能让某人知道当前数据是否与原始数据匹配。它不允许任何人或以任何方式帮助修复数据。也就是说，如果我需要从备份中恢复并且我需要的文件的数据损坏，那么 MD5 实际上毫无用处。
那么，是否存在专门设计用于验证数据和修复数据的校验和？有点像用于内存的 ECC，但用于文件？
笔记：我确实找到了帕奇夫，但它似乎不是最新的，并且无法可靠地使用。虽然我可能不喜欢他们实现事物的方式，但总的来说，parchive 正是我所寻找但找不到的东西。是否存在可用于“生产”的类似 parchive 的东西？
更新：看起来好像一些档案格式支持恢复，尽管唯一主流的恢复似乎是 WinRAR。最好不要只为这一个选项而局限于一种格式，因为大多数存档格式（链接列表中 75% +/-）似乎不支持恢复。
答案1
为此，我使用 Reed-Solomon 制作了一套工具，并称之为pyFileFixity（请参阅此处查看所含工具列表）。它主要通过命令行工作，但如果您真的想尝试它，也可以提供一个实验性的 GUI（只需--gui在命令行上使用）。
我将此工具设计为开源且可靠，其单元测试率为 83%（分支覆盖率）。整个库都经过了广泛的注释，我自己开发了 Reed-Solomon 编解码器，全部使用纯 Python（因此整个项目都是独立的，没有外部库），因此它是面向未来的（只要您有 Python 2 解释器，但Python 3 版本正在开发中）。它应该可以投入生产了，我自己也经常使用它，而且一些积极的反馈，非常欢迎任何其他反馈！
我设计的 ecc 格式应该非常稳定，并且能够抵御损坏，因为甚至可以纠正 ecc 文件（请参阅 repair_ecc.py 和索引文件）。该项目将为您提供一切来整理您的数据并测试您的整理方案（请参阅 filetamper.py 和 resilency_tester.py，您可以使用描述整理方案的类似 makefile 的文件来测试整个整理方案，因此您可以包含文件转换、zip 压缩、pyFileFixity ecc 计算或其他 ecc 计算方案等，并测试您的整理管道是否可以承受一定程度的随机数据损坏）。
然而，限制在于计算需要相当长的时间，目前的速度约为 1MB/s，尽管我计划使用并行性将速度提高四倍。不过，您可以将其视为一种限制，不幸的是，我认为没有任何更快的成熟纠错码（Reed-Solomon 几乎是唯一成熟的纠错码，LDPC 即将问世但尚未实现）。
如果您不需要确保整个数据完整性而是需要确保大部分数据完整性，那么另一种方法是使用非固实存档算法（例如 ZIP DEFLATE），然后使用 header_ecc.py（在 pyFileFixity 中提供）仅在标头上计算 ECC 哈希值。这将确保您的存档始终可打开，并且其中的大部分数据将不可压缩，但它无法纠正所有数据篡改。
还有DAR 存档格式，TAR 的替代品，允许以非固实方式压缩（因此可以对损坏的档案进行部分解压）和基于 PAR2 的恢复哈希计算，还提供目录隔离（即元数据，例如作为备份单独保存的目录树）。但老实说，我认为使用 PAR2 在速度方面不会有太大的提升，而且在冗余方面会损失很多（PAR2 格式也是基于 Reed-Solomon 的，但它有很多限制，而我的库没有这些限制，而且 PAR2 有点过时了……）。
因此，您必须考虑复制数据（存储空间）还是计算 ecc 哈希（CPU 时间和电力消耗）会花费更多。就存储而言，ecc 哈希可以是任意大小，但通常 20%~30% 的保护就足够了（光盘只有 ~5%，硬盘更少，而且它已经运行得很好了！）。
如果您重新考虑将复制作为一种可行的替代方案，那么您也可以更正数据，前提是您确保至少制作 3 份存档副本。然后，您可以使用按位多数投票来从数据损坏中恢复（pyFileFixity 提供了一个 python 脚本来执行此操作：replication_repair.py）。即使弹性率相同，这也不如 ecc 代码那么有弹性：3 个副本为您提供 33% 的弹性率（即 3 上的 2 个冗余副本除以 2，这是理论极限），但窗户保护仅为 1 个“ecc”（而不是“备用”）字节，用于 3 个字节，而使用 pyFileFixity 或 PAR2 的真正 ecc 代码，窗口最多为 255 个字节：您可以通过将 168 个字节分配为 ecc 字节来保护 255 个字节（因此，在任何文件中的任何位置，您都有 (255-168)=87 个字节受 168 个 ecc 字节保护）。实际上，弹性率 = 0.5 * ecc 字节比率，因此您需要 66% ecc 字节的比率才能获得 33% 的弹性率。但最终，您有一个复制方案，需要 2 倍原始档案大小才能实现 1/3 字节的受保护窗口，而 ecc 方案仅需 0.66 倍额外空间即可实现 87/255 字节的受保护。直观地说，这意味着：
- 对于复制方案，如果损坏的字节超过 1 个，则该字节丢失。
- 而对于 ecc 方案，你需要损坏超过 87 个字节连续丢失它们。如果损坏的字节分布在整个档案中，这不是问题，因为 87 个字节的限制是每个 255 个连续字节的窗口。
总而言之，ecc 方案几乎总是更可靠因为他们有一个更大的窗口尺寸， 但复制是最快的通常来说，最便宜的进行文件更正的方法（因为现在存储很便宜）。