Файл есть. Он открывается. Это не значит, что он цел.

Повреждение данных — процесс тихий. Файл не исчезает, не выдаёт сообщение об ошибке. Он просто становится немного другим. Иногда это видно сразу — архив не распаковывается, видеофайл показывает артефакты. Чаще — незаметно до тех пор, пока не понадобится именно этот файл.

Что такое bit rot

Bit rot — буквально «гниение битов» — собирательное название для тихого повреждения данных без видимой причины.

На жёстком диске магнитный домен меняет полярность из-за теплового шума. На SSD ячейка флеш-памяти теряет заряд. На оптическом диске деградирует отражающий слой. На ленте возникает физический дефект поверхности. Результат один: несколько битов в файле становятся другими.

Операционная система не замечает этого. Файловая система хранит контрольную сумму блока — но далеко не все файловые системы (NTFS по умолчанию не проверяет содержимое файлов, только метаданные). Антивирус не замечает. Программа, которая откроет файл, может не заметить — если повреждён заголовок, скорее всего откажется открывать; если повреждена середина, может открыть и показать битый результат.

Исследования Google и крупных архивных сервисов показывают: на больших хранилищах silent data corruption — не теоретический риск, а регулярное явление. Частота зависит от носителя, но ноль — не достижимая цифра.

Контрольная сумма как отпечаток файла

Идея контрольной суммы проста: алгоритм обходит каждый байт файла и вычисляет число — «отпечаток» содержимого. Если хотя бы один байт изменится, отпечаток будет другим.

Первые контрольные суммы — CRC32 — появились для обнаружения случайных ошибок передачи. 32 бита дают 4 миллиарда возможных значений, что для случайных ошибок вполне достаточно. Для хранения данных этого мало: коллизии (разные файлы с одинаковой суммой) возможны, и целенаправленно их можно создать.

MD5 и SHA-1 использовались в архивах долго. Сейчас они считаются криптографически сломанными — для них известны методы создания коллизий. Это важно в контексте безопасности, но менее критично для случайного повреждения: случайно получить коллизию всё равно практически невозможно.

Для долгосрочного архивирования правильный выбор — SHA-256.

Почему SHA-256

SHA-256 — алгоритм из семейства SHA-2, стандартизованный NIST в 2001 году. Даёт 256-битный хэш — число с 10^77 возможными значениями.

Два свойства важны для архивирования:

Лавинный эффект. Изменение одного бита в файле меняет примерно половину битов в хэше. Маленькое повреждение полностью меняет отпечаток — его невозможно пропустить.

Практическая коллизионная стойкость. Найти два разных файла с одинаковым SHA-256 — задача, вычислительно недостижимая современными средствами. Случайное совпадение хэшей при проверке означало бы не коллизию, а повреждение самих записей хэшей.

SHA-256 — это то, что используют Amazon S3 для верификации загружаемых объектов, Git для адресации коммитов, BitTorrent для проверки скачанных кусков.

Как это работает на практике

Схема простая.

При записи: вычислить SHA-256 каждого файла до записи на носитель. Сохранить список пар «путь файла — хэш» в отдельное место.

При проверке: снова вычислить SHA-256 каждого файла с носителя. Сравнить с сохранённым списком. Несовпадение — повреждение.

Сложность не в алгоритме, а в дисциплине. Хэши нужно хранить отдельно от самих файлов — иначе при повреждении носителя могут пострадать и файлы, и хэши. Проверку нужно делать периодически, а не только при восстановлении — к тому моменту может быть уже поздно.

Утилиты для ручной работы: certutil -hashfile file.ext SHA256 в Windows, sha256sum в Linux/macOS. Для большого архива это утомительно — тысячи файлов, ручное сравнение списков.

Когда повреждение обнаруживается слишком поздно

Типичная история: фотографии записаны на BD-R в 2015 году. Диски лежат в коробке. В 2025 году нужна конкретная фотография — открывается файл, выглядит нормально. Через три года решают перенести архив — оказывается, 40 файлов повреждены, несколько не открываются.

Без контрольных сумм невозможно понять, когда произошло повреждение — и есть ли ещё рабочая копия. С контрольными суммами и регулярной проверкой это становится известно раньше, пока копии ещё доступны.

Ещё хуже — повреждение при копировании. При переносе архива на новый носитель ошибка чтения может привести к тому, что на новом носителе окажется битая версия. Если старый носитель уже выброшен — потеря безвозвратная. Верификация после записи — обязательный шаг, а не опциональный.

Структура хранения хэшей

Есть несколько подходов.

Текстовый файл рядом с данными. Файл checksums.sha256 в корне архива, в формате хэш имя_файла. Читается без специального ПО, создаётся стандартными утилитами. Минус: при копировании папки легко случайно не скопировать или перезаписать.

База данных. SQLite или другой формат, хранящий пути, хэши, даты проверки. Позволяет хранить историю — когда последний раз проверялся файл, изменился ли хэш со временем. Удобнее для большого архива.

Встроенный индекс на носителе. При записи на оптический диск — включить файл с хэшами в сам образ. Тогда для проверки диска не нужен внешний источник истины.

Beresta использует второй и третий подходы совместно: хэши хранятся в базе данных проекта и включаются в HTML-индекс каждого диска. Это позволяет проверить диск даже без доступа к основной базе.

Что проверять и как часто

Рекомендуемая практика для долгосрочного архива:

  • При записи на любой носитель — вычислить хэши до записи, верифицировать после.
  • Раз в год — прогнать проверку хэшей по всем носителям, которые не менялись. Это обнаружит тихую деградацию.
  • При любом переносе данных — верификация после завершения, до уничтожения источника.

Частота зависит от объёма архива и числа носителей, но «никогда не проверять» — не вариант для данных, которые должны жить десятилетия.

Контрольная сумма не восстанавливает данные. Она только сообщает, что данные изменились. Это ценно именно потому, что даёт время: когда повреждение обнаружено рано, резервные копии ещё живы.