Контрольная сумма SFV/CRC32 хорошая и достаточно быстрая, чтобы проверять общие файлы резервных копий?

Question

У меня есть 3 терабайта, более 300 000 справочных файлов всех размеров (20, 30, 40, 200 мегабайт каждый), и я обычно регулярно их поддерживаю (не застегивал молнию). Несколько месяцев назад я потерял некоторые файлы, вероятно, из-за деградации данных (как я сделал «резервное копирование» поврежденных файлов без уведомления).

Я не забочусь о безопасности, поэтому мне не нужны MD5, SHA и т. Д. Я просто хочу быть уверенным, что файлы, которые я копирую, хороши (одни и те же биты и байты) и убедитесь, что резервные копии не повреждены после за несколько месяцев до повторного создания резервных копий.

Таким образом, мои потребности являются базовыми, потому что файлы не очень важны, и нет необходимости в безопасности (без конфиденциальной информации). Мое сомнение: формат/метод «SFV CRC/32» хорош и быстро для моих нужд? Что-то лучше и быстрее? Я использую программу ExactFile.

Есть ли контрольная сумма быстрее, чем SFV/CRC32, но это не является недостатком? Я пытался использовать MD5, но он медленный, и поскольку мне не нужна безопасность данных, я предпочел SFV/CRC32. Тем не менее, это больно, потому что есть более 300 000 файлов и занимает несколько часов, чтобы сделать контрольную сумму всех из них, даже с процессором xeon 8 ядер HT и быстрым жестким диском.

С точки зрения целостности данных есть некоторые преимущества в объединении всех файлов в одном .ZIP или .RAR вместо того, чтобы позволить им «свободно» в папках и файлах?

Некоторые советы?

Спасибо!

Answer 1

Если вы смогли количественно определить «несколько» и «некоторые» в «Несколько месяцев назад, я потерял некоторые файлы» (где «немногие» считаются замененными «каждые несколько», чтобы получить ставку) , то вы можете рассчитать вероятность ложного положительного. Однако только из этих слов, я бы сказал, да, 32-битный CRC должен быть хорошим для вашего приложения.

Что касается скорости, если у вас есть новейший процессор Intel, у вас, вероятно, будет инструкция CRC-32C, которая может сделать вычисление намного быстрее, примерно в 15 раз (см. this answer для некоторого кода.) Это может быть быстрее, запустив его на несколько ядер. Если все сделано правильно, вы должны ограничить ввод-вывод, а не расчет.

В этом случае нет никакого преимущества для связывания их в zip или rar. На самом деле это может быть хуже, если повреждение одного файла заставляет вас потерять все.

Answer 2

Если вы не получаете пропускную способность не менее 250 МБ в секунду на одно ядро, вы, вероятно, связаны с I/O или скоростью памяти. Исходная скорость хеширования CRC32 и MD5 выше, даже на многолетнем аппаратном обеспечении, предполагая несовместимую разумно оптимизированную реализацию.

Посмотрите на Crypto++ benchmark, в котором также содержится множество других алгоритмов хэширования.

Castagnoli CRC32 может быть быстрее, чем стандартный CRC32 или MD5, потому что новые процессоры имеют специальную инструкцию для него; с этой инструкцией и кучей вспомогательного кода (для одновременного хэширования трех потоков параллельно, сшивания частичных результатов с помощью бит линейной алгебры и т. д.). Вы можете ускорить хеширование примерно до 1 цикл/двоеслово. Хеши, основанные на AES, также быстро растут на последних процессорах благодаря специальным инструкциям AES.

Однако в конце не имеет значения, насколько быстро функция хеша ждет для считываемых данных; особенно на многоядерном компьютере, вы почти всегда связаны с I/O в таких приложениях, если только вы не подвергаетесь саботажу небольшими кэшами и задержками глубоких иерархий кэшей памяти.

Я придерживаюсь MD5, который не медленнее CRC32 и универсально доступен даже на самых старых машинах, практически в любой программной системе/языке, когда-либо изобретенной. Не думайте об этом как о «криптографически защищенном хэше» (чего нет, но не как о нем), но как о некотором CRC128, который так же быстро, как CRC32, но для того, чтобы столкновение стало вероятным, требуется несколько хешей для 2^64, а не только несколько десятков тысяч, как в случае CRC32.

Если вы хотите катить некоторый код, то CRC имеют некоторые достоинства: CRC файла может быть вычислен путем объединения CRC подблоков с битовой линейной алгеброй. С общими хэшами, такими как MD5, это невозможно (но вы всегда можете обрабатывать несколько файлов параллельно).

Есть куча готовых программ для вычисления хешей MD5 для файлов и каталогов fast. Я бы рекомендовал «глубокие» версии md5sum + cousins: md5deep and hashdeep, которые вы можете найти on SourceForge и on GitHub.

Answer 3

Darth Gizka, спасибо за советы. Теперь я использую md5deep 64, который вы указали. Это очень хорошо. Раньше я использовал ExactFile, который переставал быть обновленным в 2010 году, все еще 32-разрядный (без 64-битной версии). Я быстро сравнил их. ExactFile быстрее создавал дайджест MD5. Но чтобы сравнить дайджест, md5deep64 был намного быстрее.

Моя проблема - это жесткий диск, как вы сказали. Для резервного копирования и хранения я использую три Seagates с 2 ТБ каждый (7200 об/мин 64 мегабайт). С SSD процедура будет намного быстрее, но с терабайтами файлов очень сложно использовать SSD.

Несколько дней назад я сделал процедуру в части архивов: 1 tera (около 170 000 файлов). ExactFile занял около шести часов, чтобы создать дайджест SFV/CRC32. Я использовал одну из моих новейших машин, оснащенных i7 4770k (с встроенными инструкциями CRC32, 8 ядер - четыре реальных и четыре виртуальных, MB Gygabyte Z87X-UD4H, 16 RAM).

В ходе расчетов файлов ядра ЦП были практически непригодными (от 3% до 4%, максимум 20%). Жесткий диск был на 100% использован, однако была достигнута лишь небольшая часть его скорости (sata 3), большую часть времени 70 МБ/с, иногда снижаясь до 30 МБ/с в зависимости от количества вычисляемых файлов и антивируса в фоновом режиме (который я отключил позже, как это часто бывает при копировании большого количества файлов).

Теперь я тестирую программу копирования, в которой используется сравнение двоичных файлов. Во всяком случае, я продолжу использовать md5 digests. Благодарны за информацию и любые советы приветствуются.