Скрабинг раз в месяц: единственный способ узнать, что диск врёт

MAATRIX

Диск, на котором давно ничего не менялось, не значит «диск, с которым всё в порядке». Магнитный слой HDD теряет намагниченность, заряд в ячейках NAND на SSD постепенно утекает — и файл, который вы записали год назад и с тех пор не открывали, к сегодняшнему дню может тихо превратиться в набор немного других байт. Обычное чтение файла эту порчу не покажет: диск отдаст данные, ОС не пожалуется на ошибку, и всё будет выглядеть нормально — пока кто-то не попробует реально воспользоваться файлом и не обнаружит, что архив не распаковывается, а в базе не сходится контрольная сумма. Единственный способ узнать об этом раньше, чем скажет об этом сломанный файл — регулярно и целенаправленно перечитывать данные и сверять их с контрольными суммами. Это и называется скрабингом (data scrubbing).

Почему обычное чтение файлов не находит порчу данных

Файловая система вроде ext4 или XFS в норме не хранит контрольную сумму содержимого файла — она следит за метаданными (где лежат блоки, какие права, какая длина), но не за тем, совпадают ли байты внутри блока данных с тем, что туда когда-то записали. Диск снизу тоже не идеальный чёрный ящик: у HDD и SSD есть собственная коррекция ошибок (ECC) на уровне сектора, которая ловит и исправляет часть сбоев автоматически, но не все. Когда контроллер диска не может восстановить сектор через ECC, он обычно возвращает ошибку чтения — и вот эту ошибку файловая система как раз увидит. Проблема в другом классе сбоев: тех, что происходят *после* успешной коррекции ошибок на диске или вообще за его пределами — в кэше контроллера, на шине SATA/SAS, в оперативной памяти без ECC, в RAID-контроллере. Диск в этом случае искренне считает, что вернул правильные данные, и ошибки не будет вообще — ни на чтении, ни в логах.

Отсюда и термин «тихая порча данных» (silent data corruption, в обиходе — bit rot): содержимое файла изменилось, а ни одна штатная проверка при обычной работе с файлом об этом не сообщает. Обнаруживается это либо специальным сканированием с проверкой целостности, либо — что случается в разы чаще на практике — когда кто-то через месяцы или годы открывает файл и получает битый архив, повреждённую фотографию или запись в базе, не проходящую проверку схемы. К этому моменту обычно уже поздно: если ротация бэкапов на 30-90 дней, повреждённый файл давно вытеснил из бэкапа последнюю целую версию, и восстанавливать нечего. Механику самой порчи подробнее разбирал в статье про целостность данных и тихую порчу файлов — здесь сфокусируемся на практике регулярной проверки.

Отдельно стоит развеять заблуждение: RAID сам по себе от этого не спасает. Зеркало или чётность защищают от отказа целого диска, но если один диск вернул тихо испорченный блок, а массиву не с чем его сверить (обычному RAID-контроллеру часто просто не хватает независимой контрольной суммы данных), испорченные данные либо остаются как есть, либо, что хуже, размножаются на остальные диски при ребилде.

Что реально делает скрабинг

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

Практический подход делится на два случая:

• Файловая система со встроенным контролем целостности (ZFS, Btrfs) хранит контрольную сумму на каждый блок данных отдельно от самого блока и умеет по команде пройтись по всему тому, сверяя всё и исправляя расхождения автоматически, если для этого есть избыточность (зеркало, RAID-Z/RAID10, дублирование). Скрабинг здесь — встроенная команда, которую нужно только запускать по расписанию.
• Обычная файловая система без этой возможности (ext4, XFS, NTFS) ничего подобного не делает сама. Единственный рабочий вариант — вручную считать контрольные суммы файлов, сохранить их отдельно от самих файлов (в идеале — на другом диске или другом сервере) и периодически пересчитывать заново, сравнивая с сохранёнными значениями.

Оба подхода объединяет одно: без периодичности они бесполезны. Посчитанная один раз контрольная сумма фиксирует состояние на конкретный момент, но ничего не говорит о том, что случится с файлом дальше. Ценность появляется только тогда, когда проверка выполняется регулярно — по расписанию, а не «когда вспомнили».

ZFS: zpool scrub на практике

Если у вас пул ZFS, скрабинг — одна команда:

zpool scrub tank

Это запускает асинхронное сканирование в фоне; прогресс смотрится через zpool status:

zpool status tank

  pool: tank
 state: ONLINE
  scan: scrub in progress since Sun Aug 30 03:00:01 2026
        1.24T scanned at 412M/s, 640G issued at 210M/s, 3.10T total
        0B repaired, 20.65% done, 03:31:12 to go

После завершения там же появится итог: сколько блоков проверено, сколько ошибок найдено (errors: 0 — то, что вы хотите видеть) и сколько исправлено автоматически за счёт избыточности пула. Если пул зеркальный или RAID-Z и одна из копий блока не совпала с контрольной суммой, ZFS восстановит его из корректной копии сама, без вашего участия — это и есть self-healing, ради которого всё затевается.

Расписание — через cron или systemd timer:

# /etc/cron.d/zfs-scrub
0 3 1 * * root /sbin/zpool scrub tank

Раз в месяц — разумная частота по умолчанию для большинства однодисковых и небольших домашних/офисных пулов; для больших массивов с интенсивной записью и коммерческой нагрузкой многие администраторы сокращают интервал до раз в 1-2 недели, ориентируясь на объём данных и время, которое реально занимает скраб (на больших томах он может идти сутками и упирается в IOPS, поэтому слишком частый запуск начинает мешать продуктивной нагрузке). Раз в квартал — уже риск: за три месяца накопится больше тихих ошибок, чем успеет исправить единственный проход, особенно если часть данных давно не читалась вообще ничем, кроме предыдущего скраба.

Отдельно нужен мониторинг результата — сам факт запуска скраба ничего не даёт, если никто не читает вывод:

zpool status -x

Команда молча вернёт all pools are healthy, если всё в порядке, и выведет проблемный пул, если нет — удобно дёргать из cron-скрипта и слать алерт только при отклонении от нормы. Демон zed (ZFS Event Daemon) умеет слать email или дёргать вебхук при событиях вроде checksum errors или scrub finished with errors — настраивается в /etc/zfs/zed.d/zed.rc, и на проде его стоит включить, а не полагаться на то, что кто-то вручную посмотрит вывод команды через месяц.

Важный нюанс: если ошибки чтения контрольной суммы находятся, а исправлять их нечем (пул без избыточности — одиночный диск, zpool create tank /dev/sdb без mirror или raidz), ZFS честно сообщит о повреждённом файле в zpool status -v, но восстановить его сама не сможет — остаётся только бэкап. Про то, почему такой пул не даёт той защиты, ради которой обычно приходят в ZFS, — в статье про ZFS на одном диске: без избыточности скрабинг превращается из «автоматического ремонта» в «раннее предупреждение», что тоже полезно, но это другая гарантия.

Btrfs: btrfs scrub и чем он отличается

В Btrfs логика та же самая, команда другая:

btrfs scrub start /mnt/data

Проверить статус текущего или последнего скраба:

btrfs scrub status /mnt/data

UUID:             a1b2c3d4-...
Scrub started:    Sun Aug 30 03:00:12 2026
Status:           finished
Duration:         2:14:07
Total to scrub:   1.82TiB
Rate:             228.45MiB/s
Error summary:    no errors found

Как и в ZFS, Btrfs хранит контрольную сумму на каждый блок отдельно и способна исправить найденное расхождение автоматически — но только если у тома есть избыточность профиля raid1, raid10 или dup (для метаданных dup часто включён по умолчанию даже на одиночном диске, а вот для самих данных на одном диске избыточности обычно нет, если не задать её явно при создании тома). Расписание — тот же cron:

# /etc/cron.d/btrfs-scrub
0 4 1 * * root /sbin/btrfs scrub start -B /mnt/data

Флаg -B держит команду на переднем плане до завершения — удобно для cron, чтобы получить код возврата и вывод в лог, а не только событие запуска. Дополнительно стоит периодически смотреть btrfs device stats /mnt/data — там накапливаются счётчики ошибок чтения/записи/повреждений по каждому устройству отдельно от результатов скраба, и рост счётчика между проверками — сигнал присмотреться к конкретному диску даже без ошибок в самом скрабе.

Стоит знать заранее: Btrfs исторически менее надёжен на профилях raid5/raid6 — там остаются известные проблемы с write hole при сбоях питания, из-за которых для продакшна такие профили обычно не рекомендуют. Для raid1/raid10/одиночного диска — рабочий и достаточно зрелый вариант. Сравнение ZFS и Btrfs по зрелости и сценариям использования — в статье ext4, XFS, ZFS, Btrfs: как выбрать.

Обычные ext4/XFS: скрабинг вручную через контрольные суммы

У ext4 и XFS нет встроенного механизма проверки целостности данных — если переход на ZFS или Btrfs невозможен или избыточен (система уже эксплуатируется годами, переезд дорог), единственный рабочий вариант — собрать скрабинг руками из стандартных утилит. Идея та же: посчитать и сохранить контрольные суммы, затем периодически пересчитывать заново и сравнивать.

Базовый вариант — sha256sum:

find /data -type f -print0 | xargs -0 sha256sum > /secure/checksums-2026-08.txt

Через месяц — пересчитать и сравнить с предыдущим снимком:

sha256sum -c /secure/checksums-2026-08.txt --quiet 2>&1 | tee /var/log/scrub-report.log

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

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

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

rsync -avn --checksum /data/ backup-host:/data-mirror/ | grep -v '^$' > /var/log/scrub-diff.log

Флаг -n (dry-run) означает, что rsync ничего не перезапишет — только покажет, какие файлы отличаются по содержимому, даже если у них совпадают размер и время модификации (обычный rsync без --checksum полагается именно на эти два признака и тихую порчу может не заметить вовсе).

Расписание, ресурсы и что делать при находке ошибок

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

И ZFS, и Btrfs дают приоритет пользовательскому I/O над скрабом по умолчанию, но на слабом железе или сильно загруженном диске эффект всё равно заметен. Практический приём — запускать по ночам или в окно минимальной нагрузки и, если инструмент поддерживает, ограничивать скорость:

# ZFS: пауза и возобновление вручную при необходимости
zpool scrub -p tank    # пауза
zpool scrub tank       # возобновление с того же места

Что делать, когда скраб находит ошибку — зависит от того, есть ли избыточность:

Обнаруженная скрабом ошибка — повод не только восстановить файл, но и проверить диск отдельно: SMART-атрибуты (smartctl -a /dev/sdX) далеко не всегда покажут проблему раньше скраба — известны случаи, когда диск по SMART полностью здоров, а тихая порча происходит из-за неисправного кабеля или контроллера, а не носителя (разбор одного такого инцидента — в статье диск был здоров по SMART, а данные бились: виновником оказался кабель). Скраб и SMART проверяют разные вещи и дополняют друг друга, а не заменяют один другой.

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