Контрольная сумма для восстановления файла

Question

Существует ли контрольная сумма файла, предназначенная специально для восстановления одного файла (архива) с повреждением данных? Что-то простое, например, хеш, который можно использовать для восстановления файла

Я пытаюсь заархивировать некоторые резервные копии домашних и деловых файлов (не медиа-файлов), сжимая их и датируя их. Самый большой архив в настоящее время работает около 250 ГБ. После создания архива я сделал контрольную сумму MD5, перенес архив на другой диск, затем использовал MD5 для проверки правильности передачи файлов и сохранил хеш MD5 вместе с архивами для последующей проверки. Я планирую пытаться архивировать эти резервные копии 1-2 раза в год и хранить их на жестком диске и лентах, как позволяет бюджет.

Текущий формат архива "Zipx" с самыми высокими настройками.

Учитывая, что в настоящее время объем информации составляет около 1-2 ТБ в год, я предполагаю, что приходится иметь дело с какой-то порчей данных; особенно учитывая, что эти файлы находятся на потребительских дисках. Добавьте к этому то, что резервные копии в конечном итоге переносятся с диска на диск, на ленту и обратно, что первоначальный архив объемом 250 ГБ может содержать много терабайт записанных и прочитанных данных, увеличивая риск повреждения данных. А проверка MD5 после каждой передачи добавляет много времени, так как проверка MD5 ограничена вводом / выводом; проверка MD5 для архива объемом 250 ГБ занимает много времени, умноженного на все архивы, и MD5 обязательно будут проверяться не так часто, как это необходимо.

Итак, предположения таковы:

1. Данные будут повреждены
2. Мы не узнаем об этом до тех пор, пока это не станет фактом.
3. Из-за бюджетных ограничений и отсутствия "критически важных" у нас нет нескольких копий одних и тех же архивов резервных копий, только разные итерации резервных копий.
4. Мы хотим свести к минимуму копии наших резервных копий, одновременно защищая от повреждения данных.
5. Если один или два файла в архиве действительно повреждены, и мы теряем данные при попытке восстановить; жизнь будет продолжаться. Это не критически важная вещь.
6. Архивы являются вторичной резервной копией и, надеюсь, не будут использоваться чаще, чем пару раз за десятилетие или меньше. Оперативная резервная копия существует без сжатия.

С этим предположением, как мы защищаем от повреждения данных.

Хранение хеша MD5 позволяет только кому-то узнать, соответствуют ли текущие данные исходным данным или нет. Это не позволяет кому-либо или как-либо помочь восстановить данные. То есть, если мне нужно восстановить из резервной копии и иметь поврежденные данные в файле или файлах, которые мне нужны, MD5 практически бесполезен.

Так есть ли контрольная сумма, специально разработанная для того, чтобы не только проверять данные, но и восстанавливать их? Вроде как ECC для памяти, но для файлов?

Примечание: я нашел parchive, но он не выглядит актуальным и надежно используемым.Хотя мне может не нравиться то, как они реализовали вещи, в целом parchive - это именно то, что я ищу, но не могу найти. Существует ли что-то вроде parchive, готовое к "производству"?

Обновление. Похоже, что некоторые форматы архивов поддерживают восстановление, хотя единственным распространенным форматом является WinRAR. Было бы предпочтительнее не блокироваться в формате просто для этого варианта, так как большинство форматов (75% +/- в связанном списке), по-видимому, не поддерживают восстановление.

Answer 1

Для этого я создал набор инструментов, используя 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-байтов, поэтому для получения 33% -го уровня устойчивости необходимо соотношение 66%. Но, в конце концов, у вас есть схема дублирования, которая требует 2-кратного размера исходного архива, чтобы получить окно с защитой в 1/3 байта, тогда как схема ecc требует всего 0,66-кратного дополнительного пространства для достижения защиты 87/255 байт. Интуитивно это означает, что:

• для схемы дублирования, если поврежден более 1 байта, байт теряется.
• в то время как для схемы ecc вам нужно получить более 87 поврежденных байтов подряд, чтобы потерять их. Если поврежденные байты распределены по всему архиву, это не проблема, поскольку ограничение в 87 байтов на окно составляет 255 последовательных байтов.

Подводя итог, можно сказать, что схемы ecc почти всегда более надежны, поскольку имеют больший размер окна, но дублирование - это самый быстрый и, как правило, самый дешевый способ исправления файлов (поскольку хранилище в наши дни дешевое).