Целостность данных: как обнаружить тихую порчу файлов

MAATRIX

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

Что такое тихая порча данных и откуда она берётся

Тихая порча данных (в англоязычной литературе — silent data corruption, реже bit rot) — это ситуация, когда содержимое файла на диске меняется без ведома владельца, а операционная система при этом не сообщает об ошибке. Диск возвращает данные, физический носитель и контроллер считают операцию успешной, файловая система не видит противоречий — а по факту несколько бит в файле уже не те, что были записаны изначально.

Источников у проблемы несколько, и ни один не редкость на масштабе месяцев и терабайт:

• Деградация магнитного или NAND-носителя. На HDD со временем ослабевает намагниченность отдельных секторов, на SSD — заряд в ячейках NAND постепенно «утекает», особенно если диск подолгу лежит без питания или пишется на пределе своего ресурса.
• Ошибки контроллера диска или RAID-контроллера. Прошивка сама по себе не идеальна, а на дешёвых или устаревших контроллерах вероятность единичного сбоя выше, чем хочется думать.
• Ошибки в оперативной памяти без ECC. Если сервер пишет через кеш без коррекции ошибок, единичный сбой бита в RAM может попасть на диск как часть «нормально записанных» данных ещё до того, как файловая система вообще увидит проблему.
• Космическое излучение и электромагнитные помехи, вызывающие единичные сбои бита (single event upset) — статистически ничтожная вероятность для одного файла, но на массиве в десятки терабайт годовая вероятность хотя бы одного такого события уже вполне ощутима.
• Проблемы шины передачи данных (SATA/SAS-кабели, разъёмы, объёмные RAID-массивы) — тоже могут исказить единичные биты при передаче, если контрольная сумма на этом уровне слабая или отсутствует.

Ключевая деталь: классические файловые системы вроде ext4 или XFS в своей стандартной конфигурации проверяют целостность метаданных (структуры файловой системы), но не проверяют контрольную сумму содержимого самого файла. Диск говорит «я прочитал сектор, ошибок нет» — и на этом файловая система останавливается. Если физический сектор вернул не те данные, что были записаны, но без явной ошибки чтения (CRC-ошибки или bad sector), никто в цепочке этого не заметит.

Чем тихая порча коварнее явного отказа диска

Явный отказ диска — по-своему «удобная» проблема. Диск начинает сыпать ошибками ввода-вывода, SMART показывает рост reallocated sectors, dmesg заполняется сообщениями об I/O error, мониторинг диска (если он вообще настроен — см. материал о том, как проверить, что бекап рабочий, там разбирается похожая по духу ловушка «раз процесс завершился без ошибки, значит всё хорошо») моментально поднимает алерт. Реакция понятная: заменить диск, восстановиться из бэкапа или RAID, жить дальше.

Тихая порча ведёт себя ровно наоборот:

1. Нет никакого сигнала в моменте. Ни в логах, ни в SMART, ни в мониторинге. Испорченный бит просто существует в файле — и всё.
2. Проблема может годами оставаться незамеченной. Файл, который никто не читает целиком (архив, старый бэкап, редко используемый конфиг, фотография в дальней папке фотоархива), может лежать испорченным неопределённо долго — пока кто-то не откроет именно этот файл и не столкнётся с повреждённым изображением, битым архивом или некорректным результатом вычислений.
3. Обнаруживается на этапе использования, а не на этапе хранения. Типичный сценарий: пользователь распаковывает старый .tar.gz и получает CRC error где-то в середине архива; или база данных читает страницу с испорченными данными и падает с ошибкой целостности; или фотография при открытии показывает характерные полосы искажения в нижней части кадра. К этому моменту у вас на руках уже не «была бы проблема», а «файл нужен прямо сейчас, и он битый».
4. Разработчик или администратор склонен доверять успешному коду возврата. Программная логика вида «если read() вернул данные без ошибки — значит, данные корректны» встроена почти везде, потому что в большинстве случаев это действительно так. Тихая порча — редкое, но реальное исключение из этого допущения.

Ловушка бэкапов: почему резервная копия не спасает

Самое неприятное свойство тихой порчи — она обходит стандартную стратегию защиты от потери данных. Бэкап защищает от удаления, от отказа диска, от ошибки администратора («rm -rf не туда»), от шифровальщика. Но бэкап не знает, что копируемый файл уже испорчен — он просто добросовестно копирует байты, которые ему подсунула файловая система для чтения.

Получается следующая последовательность:

1. Файл незаметно портится на исходном диске.
2. Ночной cron запускает rsync, restic, borgbackup или любой другой инструмент бэкапа — все они читают файл штатным системным вызовом, видят «чтение успешно, ошибок нет» и добросовестно копируют уже испорченные байты в резервную копию.
3. Через несколько циклов ротации бэкапов исходная неповреждённая версия файла может быть вытеснена из истории (если глубина хранения ограничена, а инцидент обнаружен не сразу).
4. В какой-то момент кто-то пытается воспользоваться данными — распаковать архив, открыть документ, восстановить базу — и обнаруживает, что и «оригинал», и «резервная копия» одинаково испорчены.

Это ровно та причина, по которой миф «раз бэкапы идут без ошибок — значит, с данными всё в порядке» опасен — подробнее эта логика разобрана в материале «РАID — это резервная копия»? и в истории о том, как бэкапы шли год и оказались нерабочими: успешное завершение процесса копирования — это подтверждение того, что процесс отработал, а не подтверждение того, что скопированные данные корректны. Это разные вещи, и разница между ними как раз и есть тихая порча данных.

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

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

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

Базовая команда для одного файла:

sha256sum /data/archive/2026/report-q2.tar.gz > /data/archive/2026/report-q2.tar.gz.sha256

Для целого каталога — рекурсивно посчитать суммы всех файлов в один манифест:

find /data/important -type f -print0 | sort -z | xargs -0 sha256sum > /var/lib/integrity/important-2026-08.manifest

Проверка спустя время:

sha256sum -c /var/lib/integrity/important-2026-08.manifest

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

Важные практические нюансы:

• Манифест нужно хранить отдельно от проверяемых данных — на другом диске, а лучше на другом сервере или в объектном хранилище. Иначе вы проверяете целостность данных с помощью контрольной суммы, которая могла испортиться вместе с ними.
• Проверка должна быть регулярной, а не разовой. Разовый расчёт контрольных сумм фиксирует состояние на конкретный момент, но не отслеживает изменения. Смысл появляется только при повторных прогонах по расписанию — раз в неделю или раз в месяц, в зависимости от критичности данных.
• Различайте осознанное изменение и порчу. Если файл регулярно перезаписывается (логи, базы данных, рабочие документы), для него подход с фиксированной контрольной суммой не подходит напрямую — такие данные разумнее защищать через версионированные снапшоты бэкапа, а sha256-манифест имеет смысл именно для «холодных», редко меняющихся данных: архивов, медиатеки, долгосрочных бэкапов, юридически значимых документов.
• sha256sum достаточно надёжен для обнаружения случайной порчи. Более старый md5sum тоже подойдёт для этой узкой задачи (речь не о защите от намеренной подделки, а о выявлении случайного искажения битов), но раз уж вы пишете скрипт заново — разумнее сразу взять sha256sum, он не медленнее на практике на современном железе и при этом надёжнее.

Автоматизация: регулярная массовая проверка по расписанию

Ручной прогон sha256sum -c полезен, но по-настоящему работает только тогда, когда встроен в расписание и результат кто-то видит. Минимальная рабочая схема на cron:

#!/bin/bash
# /usr/local/bin/integrity-check.sh
MANIFEST=/var/lib/integrity/important.manifest
LOG=/var/log/integrity-check.log

date >> "$LOG"
sha256sum -c "$MANIFEST" >> "$LOG" 2>&1

if grep -q FAILED "$LOG"; then
    echo "Integrity check FAILED, see $LOG" | mail -s "ALERT: data integrity" admin@example.com
fi

# crontab -e
0 3 * * 0 /usr/local/bin/integrity-check.sh

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

Концептуально существует отдельный класс специализированных инструментов именно для этой задачи — регулярной массовой проверки контрольных сумм больших деревьев каталогов. Их общая идея:

• ведут собственную базу контрольных сумм (обычно в отдельном файле или SQLite-базе, не рядом с проверяемыми данными);
• умеют показывать не просто «изменилось/не изменилось», а diff — какие именно файлы новые, какие удалены, у каких изменилось содержимое, у каких — только права доступа или время модификации;
• поддерживают инкрементальные прогоны, чтобы не пересчитывать хеши всего дерева каждый раз с нуля, если часть файлов заведомо не менялась (по mtime и размеру), что существенно экономит время на больших объёмах;
• умеют формировать отчёт для интеграции с системой мониторинга или отправки алертов.

Если у вас счёт файлов идёт на сотни тысяч, а данные действительно критичны, отдельный инструмент такого рода избавляет от необходимости дописывать эту логику самостоятельно. Для небольшого набора файлов (конфиги, ключевые архивы, юридически значимые документы) связки find + sha256sum + cron вполне достаточно — сложность инструмента должна соответствовать масштабу задачи, а не наоборот.

Файловые системы со встроенными контрольными суммами: ZFS и btrfs

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

ZFS хранит контрольную сумму для каждого блока данных в метаданных родительского блока (не рядом с самими данными, а в дереве метаданных выше по иерархии — это защищает от ситуации, когда испортились и данные, и их контрольная сумма одновременно). При каждом чтении ZFS пересчитывает контрольную сумму блока и сравнивает с сохранённой. Если они не совпадают — файловая система знает о повреждении в момент чтения, а не когда кто-то случайно заметит битый файл через год. При наличии избыточности (зеркало, RAID-Z, или даже режим copies=2 на одном диске) ZFS может автоматически восстановить блок из исправной копии — то есть не просто обнаружить порчу, а вылечить её без участия администратора. Отдельно об этом — в материале о том, имеет ли смысл ZFS на одном диске: даже без второго физического диска контрольные суммы продолжают работать и как минимум надёжно сообщают о проблеме.

btrfs устроена похоже — контрольные суммы (по умолчанию CRC32C, начиная с современных версий доступны и более сильные алгоритмы) считаются для данных и метаданных, и при обнаружении несовпадения на чтении файловая система возвращает ошибку ввода-вывода вместо того, чтобы молча отдать испорченные байты. При наличии RAID1/RAID10 на уровне btrfs повреждённый блок так же может быть восстановлен автоматически со здоровой копии.

Практический эффект от этой архитектуры: вся описанная выше ручная работа с sha256sum-манифестами и cron-скриптами становится избыточной для файлов, которые лежат на ZFS или btrfs — файловая система решает эту задачу сама, прозрачно и на каждом чтении, а не по расписанию раз в неделю. Это не значит, что бэкапы становятся не нужны (контрольные суммы не защищают от случайного удаления или шифровальщика), но именно проблема тихой порчи закрывается по умолчанию. Сравнение классических и современных файловых систем по этому и другим параметрам — в материале ext4, XFS, ZFS, btrfs: как выбрать, а более подробный разбор текущего состояния btrfs — в статье «Btrfs сегодня: где хорош, где рискован».

Частые вопросы