Для этого я создал набор инструментов, используя Reed-Solomon и названный pyFileFixity ( список инструментов включен в список здесь ). Он работает в основном из командной строки, но экспериментальный графический интерфейс предоставляется, если вы действительно хотите попробовать (просто используйте --guiв командной строке).
Я сделал этот инструмент открытым и надежным, он протестирован на 83% (охват филиала). Вся библиотека тщательно прокомментирована, и я сам разработал кодек Reed-Solomon, все на чистом Python (так что весь проект автономен, внешней библиотеки нет), таким образом, он является перспективным (если у вас есть Python 2). интерпретатор, но версия Python 3 находится в разработке ). Это должно быть готово к производству, я использую это регулярно сам, и у меня было несколько положительных отзывов, и любые дополнительные отзывы очень приветствуются!
Разработанный мной формат ecc должен быть ОЧЕНЬ стабильным и устойчивым к повреждениям, так как даже можно исправить файлы ecc (см. Repair_ecc.py и файлы индекса). Проект предоставит вам все для курирования ваших данных, а также для проверки вашей схемы курирования (см. Filetamper.py и resilency_tester.py, вы можете протестировать всю схему курирования с помощью файла, подобного make-файлу, описывающего схему курирования, так что вы можете включить свой преобразования файлов, сжатие zip, расчет ecc pyFileFixity или другая схема вычисления ecc и т. д. и проверьте, может ли ваш конвейер курирования выдержать некоторое количество случайного повреждения данных).
Однако ограничение заключается в том, что вычисления будут занимать довольно много времени, скорость в настоящее время составляет ~ 1 МБ / с, хотя у меня есть планы использовать параллелизм для увеличения скорости в четыре раза. Тем не менее, вы можете рассматривать это как ограничение, и, к сожалению, я не думаю, что есть более быстрый зрелый код с исправлением ошибок (Рид-Соломон в значительной степени единственный зрелый код, LDPC идет, но еще не пришел).
Альтернативой, если вам не требуется обеспечивать целостность данных WHOLE, а скорее целостность данных, является использование нетвердого алгоритма архивации, такого как ZIP DEFLATE, а затем вычисление хэша ECC только для заголовка с использованием header_ecc.py ( предоставляется в pyFileFixity). Это гарантирует, что ваш архив всегда будет открыт, и что большая часть данных внутри будет несжимаемой, но он не сможет исправить все несанкционированные изменения данных.
Существует также формат архива DAR, альтернативный TAR, который позволяет сжимать нетвердым способом (так что возможно частичное распаковывание поврежденных архивов) и вычисление хеша восстановления на основе PAR2, а также предлагает изоляцию каталога (т. Е. Метаданные). данные, такие как дерево каталогов, сохраняются отдельно в качестве резервной копии). Но, честно говоря, я не думаю, что вы выиграете много с точки зрения скорости с PAR2, и вы много потеряете с точки зрения избыточности (формат PAR2 также основан на Риде-Соломоне, но имеет много ограничений, которые делает моя библиотека нет, а также PAR2 вроде мертвый ...).
Таким образом, вы должны подумать, стоит ли вам больше копировать данные (место для хранения) или вычислять ecc-хэш (время процессора и потребление электроэнергии). С точки зрения хранения, хеш-код ecc может быть любого размера, который вы хотите, но обычно от 20% до 30% - это МНОГО защиты (на оптических дисках только ~ 5%, на жестких дисках меньше, и он уже работает очень хорошо!) ,
Если вы рассматриваете дублирование как жизнеспособную альтернативу, вы также можете исправить свои данные, если убедитесь, что сделали как минимум 3 копии своего архива. Затем вы можете использовать побитовое большинство голосов для восстановления после повреждения данных (pyFileFixity предоставляет скрипт python для этого: replication_repair.py). Это не так устойчиво, как ecc-код, даже если коэффициент устойчивости тот же: 3 копии обеспечивают 33% -ный уровень устойчивости (т. Е. 2 избыточных копии на 3, деленные на 2, это теоретический предел), но окнозащиты составляет только 1 «ecc» (скорее «запасной») байт для 3 байтов, тогда как с реальным кодом ecc, использующим pyFileFixity или PAR2, окно имеет длину до 255 байтов: вы защищаете 255 байтов, назначая 168 байтов в качестве байтов ecc ( таким образом, у вас есть (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 почти всегда более надежны, поскольку имеют больший размер окна, но дублирование - это самый быстрый и, как правило, самый дешевый способ исправления файлов (поскольку хранилище в наши дни дешевое).