pyFileFixity 3.1.4

快速入门

在Python 3上运行，最高至Python 3.12-dev。也支持PyPy 3。

• 在Python 3上安装或更新

pip install --upgrade pyfilefixity

• 对于Python 2.7，最新可用的版本是v3.0.2

pip install --upgrade pyfilefixity==3.0.2 reedsolo==1.7.0 unireedsolomon==1.0.5

• 安装后，可以从名为

  pff

  的集中接口脚本访问工具套件，该脚本提供多个子命令，要列出它们

pff --help

您应该看到

usage: pff [-h]
           {hash,rfigc,header,header_ecc,hecc,whole,structural_adaptive_ecc,saecc,protect,repair,recover,repair_ecc,recc,dup,replication_repair,restest,resilience_tester,filetamper,speedtest,ecc_speedtest}
           ...

positional arguments:
  {hash,rfigc,header,header_ecc,hecc,whole,structural_adaptive_ecc,saecc,protect,repair,recover,repair_ecc,recc,dup,replication_repair,restest,resilience_tester,filetamper,speedtest,ecc_speedtest}
    hash (rfigc)        Check files integrity fast by hash, size, modification date or by data structure integrity.
    header (header_ecc, hecc)
                        Protect/repair files headers with error correction codes
    whole (structural_adaptive_ecc, saecc, protect, repair)
                        Protect/repair whole files with error correction codes
    recover (repair_ecc, recc)
                        Utility to try to recover damaged ecc files using a failsafe mechanism, a sort of recovery
                        mode (note: this does NOT recover your files, only the ecc files, which may then be used to
                        recover your files!)
    dup (replication_repair)
                        Repair files from multiple copies of various storage mediums using a majority vote
    restest (resilience_tester)
                        Run tests to quantify robustness of a file protection scheme (can be used on any, not just
                        pyFileFixity)
    filetamper          Tamper files using various schemes
    speedtest (ecc_speedtest)
                        Run error correction encoding and decoding speedtests

options:
  -h, --help            show this help message and exit

• 每个子命令都提供自己的更详细的帮助说明，例如对于

  hash

  子模块

pff hash --help

• 要生成监控数据库（稍后快速检查哪些文件已损坏，但不能修复除文件系统元数据之外的内容）

pff hash -i "your_folder" -d "dbhash.csv" -g -f -l "log.txt"

注意：这也适用于单个文件，只需将“your_folder”替换为“your_file.ext”。

• 更新此监控数据库（检查新文件，但不删除已不存在的文件 - 将 --append 替换为 --remove 以删除文件）

使用以下命令进行pff hash操作，将 "your_folder" 的哈希值写入 "dbhash.csv"，并更新数据库（使用 --append 参数）：

• 后来，检查哪些文件已损坏

使用以下命令检查 "your_folder" 中的文件是否损坏，并将结果写入 "log.txt" 和 "errors.csv"：

• 使用此监控数据库通过从文件内容中提取文件scraping来恢复文件系统元数据，如文件名和目录布局

使用以下命令进行pff hash操作，将 "your_folder" 的哈希值写入 "dbhash.csv"，并启用文件scraping恢复（使用 --filescraping_recovery 参数）：

• 使用名为 hecc.txt 的文件来保护文件头

使用以下命令进行pff header操作，将 "your_folder" 的文件头写入 "hecc.txt"，并使用纠错算法 3：

• 修复文件头并将修复后的文件存储在 output_folder

使用以下命令进行pff header操作，将 "your_folder" 的文件头修复并存储在 "output_folder" 中，并使用纠错算法 3：

• 使用名为 ecc.txt 的文件来保护整个文件

使用以下命令进行pff whole操作，将 "your_folder" 的整个文件写入 "ecc.txt"，并使用纠错算法 3：

• 修复整个文件

使用以下命令进行pff whole操作，将 "your_folder" 的整个文件修复并存储在 "output_folder" 中，并使用纠错算法 3：

注意，与 hash 相比，header 和 whole 也可以检测损坏的文件，甚至文件内部哪些块，但它们的速度要慢得多。

• 尝试使用索引文件 ecc.txt.idx（索引文件与 ecc.txt 自动生成）恢复损坏的 ecc 文件 ecc.txt

使用以下命令尝试使用索引文件恢复损坏的 ecc 文件 ecc.txt，并将结果写入 "ecc_repaired.txt" 和 "log.txt"：

• 尝试在没有索引文件的情况下恢复损坏的 ecc 文件 ecc.txt（您可以从 0.0 调整 -t 参数到 1.0，1.0 产生许多误报）

使用以下命令尝试在没有索引文件的情况下恢复损坏的 ecc 文件 ecc.txt，并将结果写入 "ecc_repaired.txt" 和 "log.txt"：

• 使用存储在不同介质上的多个副本来修复您的文件

使用以下命令使用多个副本修复您的文件，并生成 "rlog.csv" 报告：

• 如果您之前已生成 rfigc 数据库，则可以使用它来增强复制修复

使用以下命令使用 rfigc 数据库和多个副本修复您的文件，并生成 "rlog.csv" 报告：

• 要测试您的恢复工具，您可以创建一个类似于 Makefile 的配置文件，并使用 Resiliency Tester 子模块

使用以下命令运行测试，将 "your_folder" 的文件复制到 "test_folder"，使用 "resiliency_tester_config.txt" 配置，并记录到 "testlog.txt"：

• 在内部，pff restest 使用 pff filetamper 以各种方案篡改文件，但您也可以直接使用 pff filetamper。

• 要在您的机器上运行编码/解码错误纠正码的速度测试

pff speedtest

• 如果 pff 命令无法正常工作，可以用 python -m pyFileFixity.pff 替换。

长期存储的问题

为什么数据会随着时间的推移而损坏？只有一个原因：熵。熵是指系统随时间变得无序的普遍趋势。数据损坏正是如此：比特顺序的无序。换句话说： 宇宙不喜欢你的数据。

因此，长期存储是一个非常困难的话题：这就像与死亡（在这种情况下，数据的死亡）作斗争。事实上，由于熵，数据最终会因为各种无声的错误（如比特老化或宇宙射线）而消逝。pyFileFixity旨在提供检测任何数据损坏的工具，同时也通过提供修复工具来对抗数据损坏。

唯一的解决方案是使用一个长期以来众所周知并使桥梁和飞机安全的原则：添加一些 冗余。

添加冗余只有两种方式

• 简单的方法是 复制 对象（也称为复制），但对于数据存储来说，这会消耗大量的存储空间，并且不是最优的。然而，如果存储成本低，那么这是一个好方案，因为它比使用错误纠正码进行编码要快得多。为了使复制工作，始终需要至少 3 个副本，以便如果其中一个失败，必须立即替换。正如水手所说：“要么带一个指南针，要么带三个指南针，但绝不要带两个，因为如果其中一个失败，你将不知道哪个是正确的。”事实上，如果有三个副本，如果你经常监控它们的完整性（例如，使用散列），那么如果其中一个失败，只需进行多数投票：两个副本给出的比特值可能是正确的。

• 第二种方式，最优的数据损坏恢复工具，是 错误纠正码（前向纠错），这是一种从您的数据中智能地生成冗余码的方法，这样您就可以稍后使用这些附加信息（即，ECC 生成 k 块分割的文件（k < n）的 n 个块，然后 ecc 码可以使用（至少）任何 k 个块来重建整个文件，其中 k 个块来自总共 n 个块）。换句话说，你可以纠正多达 (n-k) 个擦除。但错误纠正码还可以自动检测和修复错误所在位置（为你提供完全自动的数据修复！），但代价是你只能纠正 (n-k)/2 个错误。

错误纠正可能看起来有点神奇，但为了合理的直觉，它可以被视为平均损坏错误率的方式：平均而言，一个比特仍然有相同的可能性被损坏，但由于你有更多的比特来表示相同的数据，你降低了整体失去这个比特的概率。

问题是，关于错误纠正码的大部分理论和实践工作几乎都是在信道传输（如 4G、互联网等）上完成的，而不是在数据存储上，这是由于一个原因：在信道中我们处于一个空间方案（发送者和接收者都是不同空间中的实体，但在同一时间尺度上工作），而在数据存储中这是一个时间方案：发送者是你存储数据在介质上的时间 t，接收者又是你，但现在是在时间 t+x 获取数据。因此，发送者不再存在，因此你不能要求发送者再次发送一些数据，如果它太损坏了：在数据存储中，如果一个数据被损坏，它将永远丢失，而在信道理论中，如果需要，可以再次提交数据的一部分。

曾尝试将信道理论和纠错码理论应用于数据存储，其中第一个是里德-所罗门（Reed-Solomon），它催生了RAID方案。随后，为了在光盘上应对划痕恢复数据，发明了交叉交织里德-所罗门编码（CIRC），这对于技术能被消费者使用是必要的。从那时起，发明了（或重新发现了）新的不太理想但速度更快的算法，如LDPC、turbo码和喷泉码（如RaptorQ），但它们在数据存储方面仍然只有边际的研究。

该项目旨在首先实施易于评估策略（filetamper.py）和文件固定性（即检测是否存在损坏），然后目标是提供一个开放且易于使用的框架，使用不同类型的纠错码来保护和修复文件。

此外，ecc文件规范被设计得简单且具有抗损坏性，因此如果您想的话，可以自行处理它，而不必花几个小时学习代码是如何工作的（与PAR2格式相反）。

在实践中，这两种方法并非互斥，最佳做法是结合它们：用纠错码保护最宝贵的数据，然后也将不太敏感的数据复制到多个存储介质中。因此，这个数据保护工具套件，就像任何其他此类套件一样，不足以保证您的数据得到保护，您必须有一个活跃的（但频率不高、因此不会耗费时间）的数据管理策略，其中包括定期检查数据并更换每几年损坏的副本。

关于存储介质和数据保护策略的入门介绍，请参阅我写的这篇文章：https://web.archive.org/web/20220529125543/https://superuser.com/questions/374609/what-medium-should-be-used-for-long-term-high-volume-data-storage-archival/873260

为什么不能只使用RAID？

RAID对于长期数据存储显然是不够的，实际上它主要是作为一种更便宜的获得更多存储（RAID0）或更多可用性（RAID1）的数据的方法，而不是用于归档数据，即使是在中短期内。

• RAID 0就像使用多个磁盘一样使用单个磁盘，以扩展可用存储。让我们跳过这一点。

• RAID 1是将一个磁盘与另一个磁盘的位对位副本进行镜像。这对于长期存储来说完全是无用的：如果任何一个磁盘损坏，或者如果两个磁盘部分损坏，您将无法知道哪些是正确的数据，哪些是错误的。有句古话：“不要拿两支指南针：要么拿三支，要么拿一支，因为如果两支指南针指向不同的方向，您将永远不知道哪一支是正确的，也不知道两支是否都错了。”这就是三重化的原则。

• RAID 5基于三重化思想：您有n个磁盘（但至少3个），如果其中一个磁盘损坏，您可以恢复n-1个磁盘（只对1个磁盘的故障具有容错性，不是更多）。

• RAID 6是RAID 5的扩展，它更接近于纠错，因为您可以纠正n-k个磁盘。然而，目前大多数（所有？）商业可用的RAID6设备只实现了最多n-2（2个磁盘故障）的恢复。

• 无论如何，RAID无法自动检测静默错误，因此您要么必须定期扫描，要么可能会永久丢失一些数据，这种情况比您预期的要常见得多（例如，对于RAID5，只要两个磁盘在相同位上有2个静默错误，该位就无法恢复）。

• 最后，值得注意的是，硬盘确实实现了纠错码（ECC）以对抗坏扇区（否则我们将会不断丢失数据！），但它们的纠错能力有限，主要是因为ECC码短且不可配置。

相反，ECC可以纠正n-k个磁盘（或文件）。您可以任意配置n和k，例如，可以设置k = n/2，这意味着您可以从只有一半的数据中恢复所有文件（当然，前提是它们已经编码为ecc文件）。

同时也有新一代的RAID解决方案，主要是基于软件的，例如SnapRAID或ZFS，这些方案允许您配置一个具有n-k值的虚拟RAID，这是您想要的值。这就像一个ecc文件（但稍微不太灵活，因为它不是一个文件，而是一个磁盘映射，所以您不能简单地复制它或将其上传到云备份托管）。除了恢复（n-k）磁盘外，它们还可以配置为从磁盘的局部、扇区故障中恢复，而不仅仅是整个磁盘（更详细的解释，请参见Plank, James S.，Mario Blaum和James L. Hafner的“SD代码：为存储系统实际故障设计的纠删码。”FAST. 2013年。）。

RAID不适用于长期存储的另一个原因是，它假定您仅将数据存储在硬盘驱动器上。硬盘驱动器不是长期存储的好介质，有两个原因

最终，最好将数据存储介质与读取仪器分开。

我们稍后将要讨论可以使用哪些存储介质。

包含的应用程序

pyFileFixity套件目前包括以下纯Python应用程序

• rfigc.py（子命令：hash），一个哈希审计工具，类似于md5deep/hashdeep，可以计算您的文件的数据库以及它们的元数据，以便您稍后可以检查它们是否已更改/损坏。

• header_ecc.py（子命令：header），使用Reed-Solomon生成器/校正器对文件头进行错误纠正。想法是通过在文件的关键部分添加更多弹性，补充其他更常见的冗余工具，例如PAR2（相当可靠），在文件头部分添加更多弹性。使用此脚本，您可以显著提高恢复头部的机会，这将允许您至少打开文件。

• structural_adaptive_ecc.py（子命令：whole），一个可变错误纠正率编码器（类似于header_ecc.py的推广）。此脚本允许为您的文件内容生成ecc文件，而不仅仅是头部部分，使用可变弹性率：头部部分将得到最多的保护，然后每个文件的其余部分将逐步以越来越小的弹性率编码。假设是重要信息首先存储，然后数据变得越来越不具信息性（因此不那么重要，因为文件的末尾描述了不那么重要的细节）。这个假设对所有压缩格式都适用，如JPG、ZIP、Word、ODT等...

• repair_ecc.py（子命令：恢复），是一个脚本，用于修复由header_ecc.py或structural_adaptive_ecc.py生成的ecc文件的结构（即，条目和字段标记/分隔符）。目标是提高ecc文件对损坏的抵抗力，确保其结构可以被修复（在一定范围内，如果你使用索引备份文件，这通常是一个与ecc文件一起生成的伴随文件，那么这个范围非常高）。

• filetamper.py（子命令：文件篡改）是一个快速制作的文件损坏工具，它将擦除或更改指定文件中的字符。这对于测试你的各种保护策略和文件格式（例如：PAR2是否真的对损坏具有抵抗力？损坏后zip存档是否仍然可以部分提取，或者rar存档更好？等等）非常有用。不要低估这个工具的有用性，因为在使用之前，你应该始终检查你的文件格式和文件保护策略的抵抗力。

• replication_repair.py（子命令：复制）利用你通过多个存储介质上的多个数据副本来恢复数据，以防数据损坏。目标是利用你的归档文件存储在多个位置：你不可避免地会进行复制，为什么不利用它们进行修复呢？确实，保持你的数据在多个存储介质上的几个相同副本是一种好习惯，但如果发生损坏，你通常会丢弃损坏的副本并保留完好的副本。然而，如果所有副本都部分损坏，你就陷入了困境。这个脚本旨在利用这些多个副本来恢复数据，而无需生成先前的ecc文件。它通过读取你数据的所有不同副本来工作，并对每个字节进行多数投票：最常出现的那个将被保留。在工程学中，这是一种非常常见的策略，用于非常可靠的系统，如太空火箭，称为“三模冗余”，因为你至少需要3个数据副本才能使多数投票生效（但越多越好）。

• resiliency_tester.py（子命令：重测）允许你测试这里提供的脚本（或任何其他命令行应用）的损坏纠正的稳健性。你只需将你想测试的文件复制到一个文件夹中，然后脚本将文件复制到测试树中，然后它将自动随机损坏文件（你可以更改如块突发等参数），然后运行你提供的文件修复命令行，最后将生成一些关于修复能力的统计数据。这允许你轻松且客观地比较不同的参数集，甚至不同的文件修复解决方案，在你关心的数据上，以便你可以选择最适合你的选项。

• ecc_speedtest.py（子命令：速度测试）是一个简单的错误纠正码编码/解码速度测试。它允许你轻松更改测试参数。这允许你评估你的机器使用所选参数进行编码/解码的速度，这对于计划可以合理地使用错误纠正码（这很耗时）保护的文件数量非常有用。

• 已废弃：easy_profiler.py只是一个快速简单的分析工具，帮助你快速了解应该优化什么以获得更多速度，如果你想为项目做出贡献，请随时提出pull request！（欢迎Cython和其他优化，只要它们是跨平台的，并且还有一个可用的纯Python实现）。

请注意，所有工具主要是为命令行使用而设计的（输入pff <subcommand> –help以获取关于接受参数的扩展信息）。

重要提示：在生成数据库/ecc文件时使用的参数必须与修正模式下的参数相同（这对于本包中的所有脚本都适用）。当然，某些选项必须更改：-g必须变为-c以进行修正，而–update是一个特殊情况。这样做主要是出于以下两个原因：首先，仅从数据库文件中自动检测参数非常困难，并且会产生大量误报；其次（主要原因）是，将参数存储在数据库文件内对损坏的抵抗能力非常低（如果数据库的这一部分被篡改，整个数据库文件将无法读取，而如果它们存储在外部或您的内存中，数据库文件总是可访问的）。因此，建议将您用于生成数据库的参数直接记录在您将存储数据库文件的存储介质上（例如：如果是光盘，请在封面或直接在光盘上用记号笔记录参数），或者最好是牢记它们。如果您忘记了，不要慌张，参数总是存储在生成的ecc文件头部的注释中，但无论如何，您都应该尝试将它们存储在ecc文件之外。

对于用户：pyFileFixity的优势是什么？

优点

• 遵循MIT许可证的开放应用程序和规范（您可以使用它并根据自己的需求对其进行定制，或者在未来随着科学进步添加更好的解码过程，以便您可以从已生成的ecc文件中更好地恢复数据）。

• 高度可靠的文件完整性监视器：rfigc.py将使用多个属性明确地告诉您文件是否已损坏，甚至可以检查图像的头部是否有效（即：文件是否仍然可以打开）。

• 可读的ecc文件格式（与PAR2和大多数其他类似规范相比）。

• 对损坏具有高度抵抗力的ecc文件格式（不仅数据受到ecc的保护，ecc文件本身也受到关键点的保护，因为没有头部，所以每个轨道是独立的，如果某个轨道损坏无法修复，其他ecc轨道仍然可以读取，并且将生成一个.idx文件来修复ecc文件的结构，以恢复所有轨道）。

• 非常安全和保守的方法：恢复过程会在提交修复块之前检查恢复是否成功。

• 允许部分恢复（即使文件无法完全恢复，可恢复的部分也将被修复，然后无法修复的部分将从损坏版本中重新复制）。

• 支持目录处理：您可以为整个文件目录（包括任何数量的子目录和深度）编码ecc文件。

• 没有文件数量的限制，它可以递归地保护目录树中的文件。

• 可变抵抗率（包括仅头部抵抗）确保您即使在部分损坏的情况下也能始终打开文件（保存您的文件结构，以便您可以使用其他软件进行修复，如果这个脚本集不足以完全修复的话）。

• 支持擦除（空字节）甚至错误和擦除，这实际上加倍了修复能力。据我所知，这是唯一一款支持擦除的免费可用奇偶校验软件。

• 显示基于您参数的预测总ecc文件大小，以及编码/解码所需的总时间。

• 您的原始文件仍然可以访问，保护文件（如ecc文件）与您的原始数据并存。与其他数据保护方案（如PAR2）不同，PAR2将整个数据编码在par归档文件中，这些文件替换了您的原始文件，并且没有解码就无法读取。

• 开源项目，采用非常宽松的MIT许可，您可以随心所欲地使用它！

缺点

• 无法保护元数据，例如文件夹路径。路径会被存储，但不能恢复（目前还不行？如果您知道如何做，请随时贡献）。仅保护文件。因此，如果您的操作系统或存储介质崩溃并截断整个目录树，则无法使用ecc文件修复目录树，因此您也无法访问文件。然而，即使目录树丢失，您也可以使用文件抓取来提取文件，然后使用RFIGC.py重新组织您的文件。还有其他选择，请参阅以下章节：您可以使用DAR或ZIP将所有文件打包成一个单一的归档文件（这样ecc也会保护元数据），或者查看DVDisaster作为替代方案，它是一个ecc生成器，支持目录树元数据（但仅限于光盘）。

• 只能修复错误和擦除（被其他字符替换的字符），不能修复删除或插入字符。然而，这种情况在任何存储介质中都不应该发生（如果文件界限检测错误，则可能会截断，在这种情况下，pyFileFixity可以部分修复文件的已知部分，但不能恢复截断后的其余部分，除非您使用了至少0.5的恢复率，在这种情况下，任何消息块都可以仅使用ecc文件重新创建）。

• 无法从其他可用文件中重新创建缺失的文件（除非您设置了至少0.5的恢复率），与Parchives（PAR1/PAR2）相反。因此，只有当您仍然在文件系统上拥有文件（及其ecc文件）时，您才能修复文件。如果它丢失，pyFileFixity无法做任何事情（但将来会实现这一点）。

请注意，这些工具是为了数据归档（保护不再修改的文件）而设计的，而不是用于监视系统文件或保护计算机上的所有文件。为此，您可以使用直接集成错误纠正代码能力的文件系统，如ZFS。

Python中的递归/相对文件完整性生成器和检查器（即RFIGC）

递归地通过MD5和SHA1散列、大小、修改日期或通过数据结构完整性（仅限图像）生成或检查文件的完整性。

此脚本最初是为了数据归档而设计的，通过允许一种简单的方式来检查静默文件损坏。因此，此脚本使用相对路径，以便您可以轻松地计算和检查在不同介质（硬盘驱动器、光盘等）上复制的冗余数据。此脚本不是用于系统文件损坏通知，而是用于定期检查您的数据归档完整性（如果您需要此类应用程序，请参阅avpreserve的fixity）。

  -h, --help            show a help message and exit
  -i /path/to/root/folder, --input /path/to/root/folder
                        Path to the root folder from where the scanning will occ
ur.
  -d /some/folder/databasefile.csv, --database /some/folder/databasefile.csv
                        Path to the csv file containing the hash informations.
  -l /some/folder/filename.log, --log /some/folder/filename.log
                        Path to the log file. (Output will be piped to both the
stdout and the log file)
  -s, --structure_check
                        Check images structures for corruption?
  -e /some/folder/errorsfile.csv, --errors_file /some/folder/errorsfile.csv
                        Path to the error file, where errors at checking will be
 stored in CSV for further processing by other softwares (such as file repair so
ftwares).
  -m, --disable_modification_date_checking
                        Disable modification date checking.
  --skip_missing        Skip missing files when checking (useful if you split yo
ur files into several mediums, for example on optical discs with limited capacit
y).
  -g, --generate        Generate the database? (omit this parameter to check ins
tead of generating).
  -f, --force           Force overwriting the database file even if it already e
xists (if --generate).
  -u, --update          Update database (you must also specify --append or --rem
ove).
  -a, --append          Append new files (if --update).
  -r, --remove          Remove missing files (if --update).

  --filescraping_recovery          Given a folder of unorganized files, compare to the database and restore the filename and directory structure into the output folder.
  -o, --output          Path to the output folder where to output the files reorganized after --recover_from_filescraping.

标题错误纠正代码脚本

本脚本旨在与其他更常见的文件冗余生成器（如PAR2，我建议使用MultiPar）结合使用。这是对文件的一个额外保护层：通过在文件头使用更高的容错率，您可以确保将来很可能能够打开它们，避免“关键点”，也称为冗余工程中的“断裂关键点”（如果修改一个比特，整个文件可能变得不可读，通常位于头部 - 换句话说，一次打击就会使整个结构倒塌，就像无冗余的桥梁一样）。

这种方法的有趣好处是，它具有低存储（和计算）开销，并且随着文件数量的增加而线性增长，无论文件大小如何：例如，如果我们有一个40k个文件的集合，总大小为60GB，容错率为30%，头部大小为1KB（我们限制为前1K字节/字符=我们的文件头），那么，不计入每个块的哈希和其他元数据，最终的ECC文件大小约为2 * 容错率 * 文件数量 * 头部大小= 24.5 MB。如果有很多小于1KB的文件，这个大小可以更低。这对于备份如此大量文件的头部来说是一个相当低的存储开销。

脚本及其依赖项都是纯Python编写的：因此，它是完全跨平台的和开源的。默认的ecc算法（ecc_algo=3使用reedsolo）还提供了一个速度优化的C编译实现（creedsolo），如果用户平台可用，则会使用它，因此pyFileFixity默认情况下应该是快速的。或者，可以使用JIT编译器，如PyPy，但这意味着creedsolo将无法使用，因此PyPy可能会加速其他功能，但ecc编码/解码会变慢。

结构自适应错误纠正编码器

此脚本实现了一个可变错误纠正率编码器：每个文件都使用可变的容错率进行ecc编码 - 对于头部部分使用高恒定容错率（容错率阶段1，高），然后对文件内容的其余部分应用可变容错率，在文件开头附近使用更高的率（容错率阶段2，中等），然后逐渐降低到文件末尾（容错率阶段3，最低）。

这种想法是，文件的关键部分通常位于顶部，数据的重要性逐渐降低。所说的“关键”既包括关键点（例如，如果您仅篡改文件头的字符，您有很大可能丢失整个文件，即您甚至无法打开它）也包括关键编码信息（例如，归档格式通常在文件中按顺序编码压缩符号，这意味着第一个出现会被编码，然后归档只写入符号的引用。因此，第一个出现会被编码在顶部，随后对此相同数据模式的编码将只是一个符号，因此只要原始符号被正确编码并保留其信息，这就不那么重要，我们总是可以在以后尝试恢复引用符号）。此外，真正冗余的数据将放在顶部，因为它们可以大量重用，而无法过度压缩的数据将放在后面，因此，这种较少压缩数据的损坏就不那么关键，因为未压缩文件中只会改变少数字符（因为数据压缩较少，在不太压缩的数据上字符的变化对未压缩数据的影响不会很大）。

这种可变错误纠正率应允许以与标准恒定错误纠正率相同的存储量来保护文件的关键部分（例如，头部和文件开头，在如zip或jpg这样的压缩文件格式中，这通常是编码最重要的字符串的地方）。

当然，您可以设置每个阶段的容错率到您想要的值，甚至可以做到相反：设置阶段3的容错率高于阶段2，这将导致文件内容末尾的ecc更大。

此外，目前设计的ecc文件格式允许两个在所有当前的文件ecc生成器（如PAR2）中不可用的事情

1. 即使不是所有的块都可以纠正，它允许部分修复文件；（在PAR2中，只有当所有块都可以纠正时，文件才会被修复，这很遗憾，因为还有其他块可以被纠正，从而生成一个更少的损坏文件）；

2. ecc文件格式相当简单易读，任何脚本都易于处理，这允许其他软件也可以使用它（这样做也是为了提高对错误损坏的容错性，即使条目损坏，其他条目是独立的，也许可以用来使用，因此ecc非常容错。这个想法在repair_ecc.py中得到了实现，但它可以扩展，尤其是如果你知道损坏的模式的话）。

脚本structural-adaptive-ecc.py实现了这个想法，这可以看作是header-ecc.py的扩展（事实上，想法是相反的：structural-adaptive-ecc.py首先被构思，但太复杂了，然后header-ecc.py被实现为一个仅为标题的简化工作版本，然后使用header-ecc.py代码进度完成了structural-adaptive-ecc.py）。它有效工作，在我自己的需要上对数百GB的数据集进行了相当多的测试，但它并非万无一失，所以请确保您自己测试脚本，看看它是否足够健壮以满足您的需求（任何反馈都将非常受重视）！

ECC算法

您可以使用--ecc_algo开关指定不同的ecc算法。

目前，仅实现了Reed-Solomon，但它是通用的，您可以在lib/eccman.py中修改其参数。

提供了两个Reed-Solomon编解码器，它们功能上等效，并且已经彻底进行了单元测试。

• --ecc_algo 1：在2^8的伽罗瓦域中以根3和fcr=1使用第一个Reed-Solomon编解码器。这是最慢的实现（但也是最容易理解的代码）。

• --ecc_algo 2：与算法1相同，但具有更快的函数。

• --ecc_algo 3：使用第二个编解码器，这是最快的。生成的ecc将与算法1和2兼容。

• --ecc_algo 4：也使用第二个，最快的RS编解码器，但具有不同的参数（US FAA ADSB UAT RS FEC规范），因此生成的ecc与算法1到3不兼容。但不要害怕，ecc仍然可以正常工作。

关于速度的说明：此外，使用较小的–max_block_size可以大大加快操作速度！这是在光盘上快速计算RS ECC所使用的技巧。当然，您会牺牲一点容错性（因为块更小，因此您保护的字符数更少。最后，这不应该在很大程度上改变真正的容错性，但在连续块上发生大量位错误的情况下，您可能会一次性丢失整个块。这就是为什么使用RS255更好，但它非常耗时。然而，容错率仍然有效，所以对于其他任何平均大小的突发位翻转的情况，只要突发的大小小于ecc块，这不应该成为问题。）

发生灾难性事件时

待办事项：在此处写入更多内容

如果您由于存储介质（例如：您的硬盘驱动器崩溃）故障导致数据发生灾难性事件，请遵循以下步骤

1- 在硬盘损坏前，使用dd_rescue创建一个全比特位字面复制。dd_rescue的优点在于复制准确，且在遇到坏扇区时可以重试或跳过（不会在处理过程中突然崩溃）。

2- 使用testdisk来恢复分区或根据分区文件系统信息复制文件。

3- 如果无法恢复文件，可以尝试使用photorec或plaso等类似工具进行文件刮擦，作为最后的手段，仅根据文件内容提取数据（无文件名，文件类型可能不正确，文件边界可能错误，因此某些数据可能被截断等）。

4- 如果在存储介质失败之前使用了pyFileFixity，可以使用预先计算的数据库来检查文件是否完整（rfigc.py），如果不完整，可以使用header_ecc.py和structural_adaptive_ecc.py进行恢复。如果通过数据刮擦恢复了文件，因为文件将完全无序，但可以使用先前生成的数据库文件，使用rfigc.py –filescraping_recover来恢复完整名称和目录树结构。

此外，还可以尝试使用专门的修复工具修复一些文件（但请记住，此类工具不能保证与错误纠正码相同的恢复能力，并且错误纠正码可以告诉你何时成功恢复）。

• 对于tar文件，可以使用fixtar。类似工具（但较旧）：tarfix和tar-repair。

• 对于RAID挂载和恢复，可以使用Sabine Seufert和Christian Zoubek的“Raid faster - recover better”（rfrb）工具：https://github.com/lrq3000/rfrb

• 如果您的Unicode字符串被破坏（例如，您看到奇怪的符号），请尝试此脚本，该脚本将自动去除这些符号：https://github.com/LuminosoInsight/python-ftfy

• 要修复表格（二维）数据，例如.csv，请尝试Carpenter。

• 用于识别ddrescue图像中损坏文件的工具：ddrescue-ffile

保护目录树元数据

pyFileFixity的一个主要当前限制是它不能保护目录树元数据。这意味着在最坏的情况下，如果指向您使用ecc保护的根目录的inode发生静默错误，整个目录将消失，其中的所有文件也将消失。在不太糟糕的情况下，子目录可能会消失，但这仍然很糟糕，并且由于ecc文件不存储任何有关inode的信息，因此您无法恢复完整路径。

无法存储这些元数据是由于设计中的两个选择

1. 便携性：我们希望ecc文件即使在将根目录移动到另一个位置或另一个存储介质时也能正常工作（当然，inode会发生变化），

2. 跨平台兼容性：无法获取和存储所有平台的目录元数据，但我们当然可以为每个主要平台实现特定的指令，所以这一点实际上不是问题。

为了解决这个问题（目录元数据是关键点），其他软件使用一次性存储介质（即，在生成和写入ecc的同时写入数据）。这样，它们可以以比特级访问inode信息，并且可以保证inode永远不会更改。这是DVDisaster采取的方法：通过使用光学介质，它可以计算永久性的inode，因此也可以在ecc文件中编码这些信息。另一种方法是创建一个专门用于存储文件的虚拟文件系统，这样您就可以自己管理inode，然后您可以像复制zip文件一样复制整个文件系统（实际上只是一个文件，就像zip文件一样——也可以被视为一个迷你虚拟文件系统）rsbep。

在这里，pyFileFixity的可移植性原则阻止了这种方法。但您可以在您的硬盘上模拟这种解决方案，以便pyFileFixity能够正常工作：您只需将所有文件打包成一个文件。这样，您就创建了一个虚拟文件系统：在存档内部，文件和目录具有元数据，就像在文件系统中一样，但从外部来看，它只是一个文件，由我们可以编码以生成ecc文件的字节组成 - 也就是说，我们消除了inode可移植性问题，因为这些元数据存储在存档中，存档负责管理它们，我们可以像其他任何数据流一样编码这些信息！从多个文件创建存档的常用方法是使用TAR，但这将生成一个坚固的存档，这将防止部分恢复。一个替代方案是使用DAR，它是TAR的非坚固存档版本，还有许多其他功能。如果您还需要压缩，可以使用ZIP（使用DEFLATE算法）压缩您的文件（这也生成一个非坚固存档）。然后您可以使用pyFileFixity在您的DAR或ZIP存档上生成ecc文件，这样现在不仅保护了您的文件，还保护了目录元数据。

应使用哪种存储介质

由于硬盘的使用寿命相对较短（5-10年，通常更短）且需要定期插入电源插座以防止磁片退化，因此其他解决方案更可取。

我建议使用的介质是光盘（无论是蓝光、DVD - 不是CD！），因为读取设备与存储介质是分开的，技术（激光在凸起和/或凹槽上反射）是通用的，所以即使有一天技术丢失了（被新技术淘汰，因此您再也找不到读取设备，因为它已经不再销售），您可能可以使用一些软件来模拟激光读取光盘，就像CAMiLEON项目为了从BBC Domesday项目的激光视盘中恢复数据所做的那样（见维基百科）。蓝光预计使用寿命为20-50年，具体取决于它们是否是“金色存档级”，而DVD的寿命应为10-30年。CD的寿命至少为1年，最多10年，因此不适合存档。存档优化的光盘，如M-Discs，声称可以存活100年，但目前没有独立的科学证据支持这些说法。有关更多详细信息，您可以阅读我写的更详细的解释，其中包含参考资料，在StackOverflow上。

然而，光盘的限制包括它们的存储空间有限、传输速度低和可重写性有限。

一个更方便的解决方案是使用磁带，特别是使用开放标准如线性磁带开放（LTO），这确保了制造商之间的互操作性，从而降低了成本，因为竞争而降低。LTO作为一个两部件系统工作：磁带驱动器和盒式磁带（带有磁带）。有大量的LTO版本，每一代都比上一代有所改进。LTO盒式磁带的寿命比光盘短，平均为15-30年，但使用起来更加方便

• 它们提供极大的存储空间（LTO-4的每个盒式磁带就是几个TB，并且随着每个新版本的推出，存储容量大约每几年翻一番！），

• 写入速度快（大约需要5小时写入完整的盒式磁带，速度随着新版本的推出而提高，所以填充盒式磁带所需的总时间保持大致相同），

• 存储介质（盒式磁带）也与读取/写入设备（LTO磁带驱动器）分开，

• 易于重写，尽管有必要重新格式化以释放空间，但“完整镜像备份”可以通过覆盖旧磁带来定期制作。

• 作为一个开放标准，读取25年前（LTO-1是2000年）的旧版本的驱动器仍然可用。

• 15-30年的寿命对于归档来说仍然很棒！但需要积极的维护（即，每5年检查一次磁带盒，并在每个十年更换一次新的磁带盒制作完整的新副本应该基本上足够）。

• 磁带盒很便宜：LTO7磁带盒允许存储高达15 TB的数据，全新的只需60美元，翻新后的（已经使用过，但可以重写和重复使用）通常要便宜得多。这比硬盘便宜得多。

• 适合冷存储：与使用磁光盘的硬盘不同，与光盘类似，磁带盒不需要定期插入电源插座，磁带不依赖于电流就会退化，因此磁带盒可以存放在防潮、防尘、防湿的容器中，这些容器可以存放在现场之外（防火数据恢复计划）。

• 失败的LTO磁带盒恢复费用低廉且易于获取，而恢复失败硬盘上的磁性信号可能需要数千欧元/美元。LTO磁带还完全兼容DAR归档，通过错误纠正码和非固化的归档（可以部分恢复）提高了恢复的机会。

听起来很完美，对吧？然而，没有什么是完美的，LTO也有几个缺点

• 起步成本非常高：最新一代全新的LTO驱动器可能要花费数千欧元/美元。二手或翻新的旧款驱动器要便宜得多，但设置起来很困难，因为您不太可能在一个全包中找到它们，您需要将磁带驱动器从计算机系统分开，然后将其插入（更多内容将在下一节中介绍）。

• 兼容性有限：LTO标准规定，每代驱动器只需支持当前一代和前一代。然而，由于LTO标准是开放的，任何人都可以制造LTO驱动器，包括未来，因此有可能有一天某个制造商将制造出支持多个过去版本的LTO驱动器（就像有一些旧的磁带数字化器可以连接到USB，用于归档目的）。在此之前，在实践中，这意味着在升级LTO系统时，您需要逐代升级，或者如果您获得2+代驱动器，您需要保留或购买旧代驱动器来读取您的磁带，然后将它们传输到最新的驱动器。截至2023年，还有LTO1磁带驱动器以低价在二手市场上出售，这项技术在2000年发布，在2001年被LTO2淘汰，这表明旧版本的LTO磁带驱动器应该仍然很丰富。

• LTO是一种顺序技术：顺序读写非常快，但如果你想下载一个特定的文件，磁带必须完全读取到文件存储的位置，这与硬盘不同，硬盘可以进行线性或次线性时间的随机访问。

• （已解决的旧问题）在LTO-5之前，LTO-5引入了LTFS标准化文件系统，该系统允许挂载在任何操作系统文件系统上，如Windows、Linux和MacOS，各种LTO驱动器制造商使用自己的封闭源代码文件系统，通常彼此不兼容。因此，请确保购买LTO-5或更高版本的驱动器，以确保将来可以访问您的长期归档。

考虑到上述所有特性，LTO>=5似乎是最好的长期归档实际解决方案，如果配合积极的（但不太频繁的）维护过程。

然而有一个例外：如果您需要在非温带环境（10-40°C之外）中对介质进行低温存储，那么使用光盘可能更耐用，尽管LTO盒式磁带也应该能够承受更广泛的温度范围，但您需要在读取之前等待它们在读者所在的环境中进行“预热”，这样磁性元件就有时间在正常温度下稳定。

如何获取LTO磁带驱动器和系统运行

要开始使用LTO磁带驱动器，选择哪个以及如何构建自己的系统，Matthew Millman制作了一个优秀的教程，您可以在这里找到，我们在下面将在此基础上进行扩展，所以您应该先阅读这篇教程，然后再阅读下面的说明。

过程如下：首先，根据您的预算找到最高版本的二手/翻新LTO驱动器，然后找到同一代的服务器，或者制作一个最高速度的eGPU + SAS卡，该速度与磁带驱动器兼容。一般来说，您可以瞄准比最新版本低3-4代的LTO驱动器（例如，如果当前是LTO9，您可以使用便宜的价格 - 每台150-300美元）来购买LTO5或LTO6）。仅针对LTO5+，因为LTFS在LTO5之前并不存在，但请注意，一些LTO5驱动器需要固件更新才能支持LTFS，而所有LTO6驱动器都自带支持。

一旦找到二手LTO驱动器，先查看其用户手册，以确定您需要哪种SAS或光纤电缆（FC）（如果SAS，任何版本都应该工作，即使是更高版本，但旧版本将仅限制读写速度性能）。例如，这是HP LTO6驱动器的手册。只要您有适当的连接性（SAS或FC适配器），所有LTO驱动器都与所有计算机兼容。

一旦您有了LTO驱动器，然后您可以寻找一台计算机来连接LTO。基本上，您只需要一台支持SAS的计算机。如果不是，那么至少有一个空闲的PCIe或mini-PCIe插槽，以便能够连接SAS适配器。

大致来说，您只需要一台带有PCIe插槽的计算机，并获取一个SAS或FC适配器（根据您的LTO驱动器是SAS还是FC），这样您就可以连接您的LTO驱动器。目前还没有SAS到USB适配器，只有一个制造商生产带有USB端口的LTO驱动器，但它们非常昂贵，所以请坚持使用内部SAS或FC驱动器（通常您想要SAS，FC更适合长距离连接，而SAS与SATA和SCSI驱动器兼容，因此您也可以使用此协议将所有其他硬盘驱动器和LTO磁带驱动器连接到同一SAS适配器上）。

实际上，有2种不同的经济实惠的方法可供选择

• 如果您有外置磁带驱动器，那么最好的方法是购买一个（二手）eGPU外壳和一个PCIe SAS适配器，您将把适配器插入到eGPU外壳中而不是GPU卡。eGPU外壳应支持Thunderbolt，这样您就可以连接到SAS以及您的磁带驱动器：您将笔记本电脑连接到eGPU外壳，并将eGPU外壳通过eGPU外壳中的SAS适配器连接到外部磁带驱动器。截至2023年，这通常花费约150-200欧元/美元。

• 另一种选择是购买一个低占用空间的PCIe扩展坞，如EXP GDC生产的，这本质上取代了eGPU外壳。缺点是您的PCIe SAS适配器将暴露在外，但这可能更具成本效益（特别是在二手市场上，您可以以20-40欧元/美元的价格购买它们，而全新的价格是120-150欧元/美元）。但请记住，您还需要购买一个电源单元！

• 如果您拥有一台内部磁带驱动器，通常比外部驱动器便宜，那么方法就不同了：这里您得到的是一台独立的计算机，其主板可能原生支持SAS（通常是服务器的计算机），或者至少有一个PCIe插槽，可以单独购买PCIe SAS适配器，然后将您的内部驱动器插入。因此，您将无法直接将笔记本电脑连接到磁带驱动器，您将需要控制服务器（实际上只是一台标准的台式计算机）。考虑到这些要求，您可以自己制作这样的服务器，但请记住，您必须构建整个计算机，包括主板、电源、RAM、CPU、网络等。或者，最简单且通常最便宜的方法是，仅购买二手SAS硬盘服务器的旧服务器（以及其他所有组件），其代际与您的磁带驱动器相似或更晚，然后以便宜的价格购买。实际上，如果服务器有SAS硬盘，那么这意味着您也可以连接您的SAS磁带驱动器，不需要适配器！通常您可以用很便宜的价格买到它们，例如，如果您得到3-4个上一代的磁带驱动器（例如，当LTO-9是当前版本时LTO-6），那么您很容易以100-250欧元/美元的价格得到一台类似代际的服务器计算机，并且一切都已经为您准备好了。只需确保不要购买机架/刀片服务器，而是购买塔式服务器，更容易操作。在二手网站上搜索：“服务器sas”，然后检查SAS速度是否与您的磁带驱动器可以接受的速度相匹配，但如果较低或较高，也没有大问题，它可能只是较慢，但应该仍然可以工作。可能还需要购买正确的连接器，但这不是问题，只需查看您的磁带驱动器的说明书。注意：请避免HP Enterprise（HPE）服务器，因为在Smart Array的Smart Storage Battery中存在预报废的怀疑。

消耗品，磁带，也容易找到二手的，通常非常便宜，例如，LTO6磁带的价格为10-20欧元/美元一张，每张磁带存储空间为3TB到6.25TB。

使用这两种方法，到2023年，您至少需要为磁带驱动器和附件系统（eGPU外壳或专用服务器）支付约500欧元/美元，这非常好，并且只要几张磁带，就可以快速摊销，即使与最便宜的硬盘相比也是如此！

个人的现代数据管理策略

以下是一个可访问的示例整理策略，不仅适用于大型数据中心

• 获取一个LTO≥5驱动器。LTO的基本思想是，您可以将整个硬盘的副本直接倒入磁带，因为磁带盒又大又便宜。您还可以定期重新格式化和覆盖先前的副本，以较新的一个。将一些LTO磁带存放在外面，以防火灾。

• 如果您想要额外的保护，特别是通过添加错误校正码，可以使用DAR来压缩数据，并与LTO兼容。或者，可以使用pyFileFixity生成ECC码，这些码可以存储在同一个磁带盒内与文件一起，或者根据您的威胁模型存储在单独的磁带盒中。

• 可以实现两种存档计划

1. 或者，只使用LTO磁带，然后尝试使用不同品牌的磁带（以避免它们同时失败 - 同一生产线生产的磁带往往包括相同的缺陷和类似的寿命），根据冗余原则（即，“要么带一个指南针，要么带三个，但永远不带两个，因为你永远不知道哪个是正确的”），将您的数据存储在至少3个不同的副本/磁带上。

2. 可以使用LTO磁带作为唯一的存档介质，并使用其他类型的存储来备份您需要的额外两份副本：一份可以是外置硬盘，最后一份可以是SpiderOak等云备份解决方案。这种解决方案的优点是更方便：使用您的外置硬盘进行频繁备份，然后使用您的云备份在线（异地）自动备份您最关键的数据，最后不时通过镜像您的外置硬盘来更新LTO磁带上的最后一份副本。

• 对于所有计划，编目策略都是相同的

1. 每5年进行一次“小检查”：检查您的3份副本，可以通过扫描扇区或通过您自己预先计算的散列值（pyFileFixity的hash命令）。

2. 如果有错误，假设整个介质已损坏并需要更换，并且需要恢复数据：首先使用您拥有的纠错码，然后使用pyFileFixity dup命令，通过对3份副本进行多数投票来从3份副本中重建一个有效的副本。

3. 每10年进行一次“大检查”：即使介质没有损坏，也用新的介质替换它们：将旧硬盘镜像到新硬盘，将旧LTO磁带镜像到新磁带（可以是更新的LTO版本，这样您可以跟上技术的步伐），等等。

使用上述策略，您应该能够保留您能够积极编目的数据。如果您希望对事故或2份副本在5年内被损坏的风险有更强的鲁棒性，则可以制作更多的副本，最好使用LTO磁带，但也可以使用其他硬盘。

有关如何冷存储LTO驱动器的更多信息，请参阅本用户手册的第32-33页“关爱磁带”说明：用户手册。对于HP LTO6驱动器，Matthew Millman开发了一个开源命令行工具，用于在Windows上执行高级LTO操作：ltfscmd。

如果您负担不起LTO驱动器，可以用外置硬盘替换它们，因为它们最初的成本较低，但您的编目策略应更频繁地进行（即，每2-3年进行一次小检查，每5年进行一次大检查）。

pyFileFixity（或可用作补充的工具）之类的工具

以下是一些具有与pyFileFixity类似哲学的工具，如果您需要它们，可以使用它们，无论是作为pyFileFixity的替代品还是补充（pyFileFixity始终可以用来生成ecc文件）

• DAR (Disk ARchive)：类似于tar，但非固密，因此允许部分恢复和按文件访问，同时它还保存目录树元数据——参见目录隔离——它还可以使用PAR2和加密进行原生错误纠正。还支持增量备份，因此它是一个非常多功能的好工具。跨平台和开源。兼容线性磁带开放（LTO）磁性带存储（请参阅说明此处）

• DVDisaster：针对光盘介质（CD、DVD和BD/蓝光光盘）的位级错误纠正。非常好，它还保护目录树元数据，并且对损坏具有弹性（v2仍有一些关键点，但v3不会有）。

• Debian中dvbackup包的一部分rsbep工具：允许生成字节数流的ecc。如果您在Unix上或使用cygwin，这对于将备份管道到dar和/或gz非常有用。

• Thanassis Tsiodras修改的rsbep：增强了rsbep以避免关键点并提高速度。还包括一个“冻结”脚本，可以将您的文件编码到虚拟文件系统中（使用Python/FUSE），这样即使元数据如目录树也能被ecc完全保护。这是一个很棒的脚本，但未得到维护，需要由专业人士进行一些密集测试，以确保此脚本足够可靠，适用于生产。

• Parchive (PAR1, PAR2, MultiPar)：知名的错误纠正文件生成器。Parchive的优势在于ecc块依赖于多个文件：这允许从可用的文件从头开始完全重建一个缺失的文件。对于大多数人来说，效果很好，但大多数可用的Parchive生成器并不令我满意，因为1-它们不允许递归地生成目录树的ecc（除了MultiPar，即使PAR2规范允许），2-生成速度可能非常慢（即使有多进程扩展，因为伽罗瓦域超过2^16而不是2^8，这非常昂贵），3-规范对ecc文件的错误和篡改的容错性不是很强，因为它假设ecc文件不会被损坏（我也测试过，它仍然有一定的容错性，但通过规范的一些调整，它可能会更强），4-它不允许部分恢复（恢复我们可以恢复的块，跳过无法恢复的块）：在PAR2中，文件可以完全恢复，或者根本不能恢复。

• Zip（使用DEFLATE算法，使用7-Zip或其他工具）：允许创建非固化的存档，大多数计算机都可以读取（普遍的算法）。非固化存档意味着即使zip文件损坏，仍然可以解压缩正确的文件，因为文件是按块编码的，因此即使某些块损坏，解码也可以进行。一个在纯Go中实现的快速增强压缩版本（适用于长期存储）。

• TestDisk：当其他方法不起作用时用于文件恢复。

• dd_rescue：用于磁盘恢复（允许强制以位级读取整个磁盘并复制它能复制的一切，带有选项在第一次完整遍历正确扇区后稍后重试坏扇区）。

• ZFS：一个包含ecc纠正的文件系统。整个文件系统，包括目录树元数据，都受到保护。如果您想在计算机上对所有文件进行ecc保护，这是唯一的方法。

• 加密：技术上，只要您使用基于块的加密方案，例如DES，您就可以加密文件而不会丢失太多的冗余：如果一个块损坏了，它将无法解密，但其他文件的加密块应该没有问题。所以使用这样的算法加密会导致类似于deflate zip这样的非固化存档。当然，对于非常长期的存储，最好避免加密和压缩（因为您提高了单个数据块中包含的信息量，因此如果您丢失一个块，您将丢失更多的数据），但如果您确实需要，您仍然可以通过使用基于块的加密/压缩来保持高概率恢复您的文件（注意：基于块的加密可以看作是压缩的非固化存档的等价物，因为数据是在独立的块中压缩/加密的，因此允许部分解压缩/解密）。

• SnapRAID

• par2ools：一组管理par2存档的附加工具

• Checkm：一个类似于rfigc.py的工具

• BagIt 有两种 Python 实现 这里 和 这里：这是一种用于长期保存和共享归档的文件打包格式，它仅对通常添加到文件中的几个常见程序和元数据（如 MD5 校验和）进行了规范化。

• RSArmor 是一个基于里德-索罗门编码的二进制数据文件到十六进制的工具，这样你就可以将字符打印在纸上。对于小于 100 MB 的小数据集可能很有趣。

• Ent 是一个分析您文件熵的工具。对于优化错误纠正算法或您的压缩工具可能非常有意思。

• HashFS 是一个无冗余、无重复的文件系统，使用 Python 实现。**数据去重** 对于大规模长期存储非常重要：由于您希望数据冗余，这意味着您将使用额外的存储空间来存储冗余副本，这将与您的原始数据成比例。具有重复数据将消耗更多的存储空间和处理时间，而没有好处。这就是为什么在创建冗余副本之前去重数据是一个好主意：这将更快并为您省钱。去重可以是手动进行的（使用重复项删除工具），也可以使用特定文件系统（如启用去重的 zfs 或 hashfs）进行系统性和自动化的去重。

• 纸张作为存储介质：纸张不是一个很好的存储介质，因为它具有低存储密度（即，您最多只能存储大约 100 KB），它也可以像其他存储介质一样退化，但您无法自动检查，因为它不是数字的。然而，如果您感兴趣，这里有一些软件可以做到这一点：Paper key，Paperbak，Optar，dpaper，QR Backup，QR Backup（另一个），QR Backup（再次一个），QR Backup（再次），最后是一篇相关的论文。

• AVPreserve 工具，最著名的是用于监视文件更改（类似于 rfigc，但作为守护进程积极进行）的 fixity 和用于检测音频数字化工作流程中中间错误（确保您正确地将整个音频文件数字化到 WAV 文件中且无任何错误）的 interstitial。

常见问题解答

• 我可以压缩我的数据文件和我的 ecc 文件吗？

一般来说，您应该始终将 ecc 文件保持为纯文本，因此不进行压缩或加密。这是因为如果 ecc 文件被损坏，如果压缩/加密，损坏部分的解压缩/解密可能会完全破坏 ecc 文件的整个结构。

您想要保护的数据文件应保持为纯文本，但您可以选择压缩它们，如果这极大地减少了文件大小，并且如果提高了 ecc 文件的鲁棒性（因此，如果您有机会以文件大小减少换取更多的 ecc 文件鲁棒性，压缩可能是一个不错的选择）。另外，请确保选择非固定压缩算法，如 DEFLATE（zip），这样即使一些部分被损坏，您仍然可以解码正确的部分（否则，如果是一个固化的存档，如果有一个字节被损坏，整个存档可能变得无法读取）。

然而，在你压缩文件的情况下，你应该只在压缩之后生成ecc文件，以便ecc文件应用于压缩的归档文件而不是未压缩的文件，否则你可能会因为损坏部分的解压缩可能输出乱码，以及长度扩展的损坏部分（如果大小不同，Reed-Solomon将完全失控）而无法修复你的文件。

• 我可以加密我的数据文件和ecc文件吗？

永远不要加密ecc文件，这是完全无用的，甚至是反效果的。

你可以加密你的数据文件，但选择非固定算法（例如，如果我没记错的话，是AES）以便损坏部分不会阻止后续正确部分的解码。当然，加密文件会略微降低你恢复数据文件的机会（保持数据长期存在最佳方式是保持为明文），但如果真的有必要，使用非固定加密方案是一种很好的折衷方案。

你可以在加密后的数据文件上生成ecc文件，因此 之后 加密，并保持ecc文件为明文（永远不要加密或压缩它）。这根本不是安全问题，因为ecc文件不提供关于你加密文件内容的任何信息，而只是用于纠正损坏字节的冗余信息（然而，如果你在加密之前在数据文件上生成ecc文件，那么显然存在安全问题，有人可能会未经你的允许恢复你的数据）。

• 我应该使用什么介质来存储我的数据？

详情很长且有些复杂（我可能在未来写一整篇文章关于它），但简而言之，你应该使用 光盘，因为它将存储介质和读取硬件分开（例如，相对的我们有硬盘驱动器，它包含读取硬件和存储介质，所以如果其中一个失败了，你就丢失了两者）并且它很可能是未来兼容的（你只需要一个激光，它是通用的，激光的参数可以始终进行调整）。

根据科学研究，在撰写本文时（2015年），蓝光HTL光盘对环境退化的抵抗力最强。为了提高耐用性，你还可以将光盘放入完全不透光的盒子中（以避免光退化），并且你还可以将任何存储介质（不仅限于光盘，还包括硬盘驱动器和任何东西）放入 完全 密封的袋子或盒子中，并将其放入冰箱或冷冻柜中。这是自然法则：降低温度，熵会降低，换句话说，随着时间的推移退化会降低。这与数字数据相同。

• 哪种文件格式最易恢复？

很难建议一个特定的格式。我们可以做的是建议一个好的文件格式的特点

• 未来兼容性（应该在将来可读）。

• 非固定（即，划分为独立块，以便一个块的损坏不会导致其他块的解码问题）。

• 开源实现可用。

• 最小化损坏影响（即，文件有多大部分因为部分损坏而不可读？只有部分损坏的区域，还是其他有效部分？）。

• 没有魔法字节或头部重要性（即，损坏头部不会阻止打开文件）。

有一些关于最具有弹性的文件格式的研究，例如

• Volker Heydegger的《百万分之一的一个比特：关于文件中数据损坏的影响》.

• Volker Heydegger的《分析文件格式对数据完整性的影响》.

• 英国国家档案馆的《格式指南》（你需要在每个表格中查看“可恢复性”条目）。

• 什么是Reed-Solomon？

如果您对里德-索洛蒙码有任何疑问，最佳提问地点可能是这里（有令人难以置信的Dilip Sarwate）：http://www.dsprelated.com/groups/comp.dsp/1.php?searchfor=reed%20solomon

此外，您可能还想阅读以下资源

• “Reed-Solomon codes for coders”，免费实用入门教程，包含Python代码示例，在WikiVersity上部分由本软件的作者之一编写。

• “Algebraic codes for data transmission”，Blahut, Richard E.，2003，剑桥大学出版社。可在Google Books上在线阅读：Readable online on Google Books。