Проверка целостности данных: scrub в ZFS, Btrfs и аппаратных RAID. Практическое руководство 2026

Scrub это фоновая операция, которая читает каждый занятый блок данных и метаданных и сверяет его с контрольной суммой. Если checksum не совпал, ZFS или Btrfs находят целую копию в избыточности (mirror, RAID-Z, RAID1, DUP) и перезаписывают повреждённый блок правильными байтами. Аппаратный RAID работает иначе: patrol read проверяет читаемость секторов и чётность, а контрольные суммы файловой системы ему неизвестны.

Без регулярного scrub тихие повреждения (silent data corruption, bit rot) накапливаются незаметно. Файловая система отдаёт приложению байты, которые считает валидными, потому что метаданные целы, а сами данные уже изменились. Обнаруживается это обычно при восстановлении из бэкапа, при resilver после замены диска или при попытке открыть архив, который никто не читал два года.

Ниже: какие ошибки выявляет scrub, чем ZFS и Btrfs отличаются от аппаратного RAID, готовые команды и расписания для TrueNAS и Linux, метрики и пороги, а также две ошибки администраторов, которые чаще всего заканчиваются потерей данных.

Что такое scrub и почему без него нельзя гарантировать целостность данных

Обычное чтение проверяет только те блоки, которые запросило приложение, и только контрольную сумму этих блоков. Scrub проходит весь пул от начала до конца и проверяет всё, что занимает место: файлы, снапшоты, метаданные, косвенную адресацию. На пуле с 40 ТБ данных это десятки миллионов блоков, которые никогда не читаются рабочей нагрузкой, но именно они становятся источником невосстановимых ошибок.

Разница в цене ошибки. Пока блок живёт на диске, проблемы не видно. Как только он понадобился, а избыточности для починки не осталось, приложение получает ошибку ввода-вывода, а файл уходит в категорию утраченных. Производители жёстких дисков задают параметр UBER (unrecoverable bit error rate) на уровне 10^-14 для потребительских моделей и 10^-15 для корпоративных. При UBER 10^-14 чтение 12 ТБ данных в среднем даёт одну неустранимую ошибку чтения, при 10^-15 одна ошибка приходится примерно на 114 ТБ, то есть около 10% на полный проход по диску 12 ТБ. Это математика из спецификаций, а не аварийная ситуация: она объясняет, почему отказ второго диска во время перестроения массива так часто заканчивается потерей тома.

Скрытые дефектные сектора встречаются чаще, чем принято думать. Анализ телеметрии накопителей, выполненный группой исследователей Висконсинского университета совместно с NetApp (публикация FAST 2007, более 1,5 млн дисков за 32 месяца), показал, что как минимум один скрытый нечитаемый сектор появился у 8,5% дисков класса nearline SATA, у 1,9% корпоративных SATA и у 0,5% Fibre Channel. Без контрольных сумм большая часть этих дефектов остаётся незамеченной до момента восстановления.

Scrub не заменяет бэкап. Файловая система с контрольными суммами умеет вылечить блок, пока есть вторая целая копия или чётность. Если копий не осталось, scrub только зафиксирует ошибку. Резервная копия на другом носителе закрывает то, что не может закрыть ни один массив.

Чем scrub отличается от проверки дисков утилитами вроде fsck

fsck разбирает структуру файловой системы: суперблок, дерево каталогов, карты свободных блоков, ссылки на inode. Он ищет логические несоответствия и умеет их исправлять, иногда за счёт удаления повреждённых объектов. Работает fsck на размонтированной файловой системе, а его правки меняют метаданные на диске. Для xfs аналог называется xfs_repair и тоже требует размонтирования.

Scrub решает другую задачу. Он читает блоки и сверяет их с контрольными суммами, ничего не удаляя и не переписывая без необходимости. Файловая система остаётся смонтированной, приложения продолжают работать. Главное отличие в том, что fsck не видит silent corruption: если указатели и метаданные согласованы, а байты внутри файла изменились, утилите просто не с чем сравнивать. В ext4 контрольные суммы есть у метаданных, но не у пользовательских данных, в XFS v5 защищены CRC32c только метаданные. Поэтому на таких файловых системах подмена данных обнаруживается приложением или вообще не обнаруживается.

Ещё один частый вариант - проверка поверхности утилитами вида badblocks или длинный SMART-тест. Эти инструменты заставляют диск читать все сектора и сообщать о тех, которые не читаются. Контрольных сумм у них нет, поэтому корректно прочитанный, но уже испорченный сектор они считают здоровым.

Какие ошибки выявляет scrub: checksum, чтение, запись

Практика сводится к трём категориям, и в ZFS они видны прямо в zpool status по столбцам READ, WRITE и CKSUM.

Несовпадение контрольной суммы (CKSUM). Данные изменились после записи: деградация магнитного слоя, сбой контроллера диска, ошибка в оперативной памяти сервера, тихо испортившая блок в кэше, обрыв питания в момент записи. Если есть вторая копия, ZFS и Btrfs молча восстанавливают блок.
Ошибка чтения (READ). Диск не может отдать сектор: сбойная поверхность, ошибка позиционирования, проблема с кабелем или портом. Формально это не checksum-ошибка, но именно она убивает перестроение массива, потому что при resilver данные надо прочитать со всех остальных дисков.
Ошибка записи (WRITE). Scrub почти не пишет данные, он читает. Ошибки записи фиксируются в обычной работе и в логе пула, а scrub показывает их последствия: например, блок, который не удалось записать на один из дисков избыточного vdev.

Отдельно стоит помнить про ZFS и метаданные: пул хранит до трёх копий метаданных (Ditto Blocks), поэтому даже на одиночном диске scrub часто может починить дерево каталогов, хотя пользовательские данные восстановить не из чего. Btrfs в профиле single тоже починить ничего не может и работает как детектор: показывает, что блок испорчен, но валидной копии нет.

Механизм	Что проверяет	Контрольные суммы	Может восстановить
ZFS scrub	Все занятые блоки пула, включая снапшоты и метаданные	Да: fletcher4, sha256, sha512, skein, edonr, blake3	Из mirror, RAID-Z, Ditto Blocks
Btrfs scrub	Блоки данных и метаданные файловой системы	Да: crc32c, xxhash, sha256, blake2	Из RAID1, RAID10, DUP, RAID1C3
mdadm check	Копии блоков и чётность на уровне устройства	Нет, сверка копий между собой	Да, командой repair
patrol read	Сектора всех дисков массива	Нет	Нет, только отчёт
consistency check	Данные и чётность тома	Нет	Перезапись чётности

Как работает scrub в ZFS: механика, команды и особенности

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

Scrub обходит все выделенные блоки пула, включая снапшоты, и при несовпадении суммы пытается восстановить блок: из зеркала, из чётности RAID-Z или из второй копии метаданных. Свободное место не сканируется: незанятые блоки нечего проверять, поэтому на полупустом пуле проверка проходит в разы быстрее. В один момент времени на пуле может выполняться только один scrub, повторный запрос вернёт сообщение о том, что проверка уже идёт.

Запуск и мониторинг scrub в ZFS: команды и интерпретация вывода

Базовый набор команд выглядит так:

Запуск проверки: zpool scrub tank
Статус и результат: zpool status tank
Подробности с перечнем файлов: zpool status -v tank
Приостановить: zpool scrub -p tank, возобновить повторным zpool scrub tank
Остановить: zpool scrub -s tank
Дождаться завершения в скрипте: zpool scrub -w tank
История событий пула: zpool events -v, очистка истории: zpool events -c

Во время работы zpool status показывает строку вида scan: scrub in progress since Sat Sep 5 22:04:31 2026, 2.10T scanned at 1.05G/s, 1.90T issued at 972M/s, 2.50T total, 75.6% done, 00:10:23 to go. Значение scanned это объём, который уже прочитан, issued - объём, по которому проверка завершена содержательно, total - общий размер данных в пуле. Расхождение между scanned и issued нормально: пул читается быстрее, чем обрабатывается очередь.

Успешный результат: scan: scrub repaired 0B in 0 days 00:42:11 with 0 errors on Sun Sep 6 03:12:04 2026 и errors: No known data errors. repaired 0B означает, что все суммы совпали. Если появилось repaired 128K, повреждение было и ZFS вылечил его из избыточности, а значит нужно посмотреть SMART дисков и понять причину. Строка errors: 2 data errors, use '-v' for a list означает неустранимые ошибки, и каждое имя файла из zpool status -v придётся восстанавливать из бэкапа.

Нагрузку на диски регулируют параметрами модуля. zfs_scrub_delay задаёт паузу между операциями чтения (по умолчанию 4) и позволяет растянуть проверку во времени, zfs_scan_min_time_ms задаёт долю пропускной способности, которую сканирование отдаёт пулу, zfs_top_maxinflight ограничивает число одновременных запросов к топ-уровню vdev. Разумная практика для нагруженной системы - увеличить zfs_scrub_delay в 5-10 раз и запускать проверку ночью.

Полезное ограничение: scrub нельзя запустить на пуле, который сейчас перестраивается. Если идёт resilver, ZFS ответит ошибкой cannot scrub while resilvering. Это защита от ситуации, когда проверка и перестроение конкурируют за одни и те же диски. Разбор сценариев с деградацией и заменой диска собран в материале про scrub и resilver в ZFS.

Настройка расписания scrub в TrueNAS

TrueNAS создаёт задачу проверки автоматически при создании пула, менять её нужно через веб-интерфейс: Storage, затем Pools, кнопка с тремя точками у пула, пункт Scrub Tasks. В открывшемся списке есть записи с параметрами Pool, Threshold days, Description и Enabled.

Откройте Storage, Pools, выберите нужный пул, затем Scrub Tasks.
Нажмите Add и укажите пул, порог в днях (Threshold days) и описание задачи.
Оставьте переключатель Enabled включённым и сохраните.

Threshold days задаёт минимальный интервал между проверками: планировщик запускает scrub, когда с прошлого прохода прошло больше указанного числа дней. Для новых пулов TrueNAS ставит 35 дней, вручную часто выставляют 30. Уменьшать значение ниже 7 дней нет смысла: проверка 100 ТБ может идти сутки и больше, а выигрыш от частоты почти нулевой.

Если нужно запустить проверку прямо сейчас, используйте кнопку Run Now в той же задаче. Дополнительный cron job с командой zpool scrub tank создаёт вторую точку входа, и такие задачи начинают конкурировать между собой, поэтому лучше ограничиться планировщиком TrueNAS. Отдельно проверьте настройки уведомлений в Alert Settings: алерт о деградации пула и о результатах scrub должен уходить не только в веб-интерфейс, но и на почту или в мессенджер. Регламент обслуживания с мониторингом и заменой дисков описан в статье про проактивное обслуживание ZFS в TrueNAS.

Настройка расписания scrub в Linux (systemd timer и cron)

В Debian, Ubuntu и производных пакет zfsutils-linux приносит готовые шаблоны systemd. Для ежемесячной проверки пула tank достаточно выполнить systemctl enable --now zfs-scrub-monthly@tank.timer, для еженедельной - zfs-scrub-weekly@tank.timer. Проверить расписание можно командой systemctl list-timers, а лог последнего запуска лежит в journalctl -u zfs-scrub-monthly@tank.service.

Если шаблонов в дистрибутиве нет, создайте два файла. Юнит /etc/systemd/system/zfs-scrub@.service с секцией Service: Type=oneshot, ExecStart=/sbin/zpool scrub %i. Таймер /etc/systemd/system/zfs-scrub@.timer с секцией Timer: OnCalendar=monthly, Persistent=true, RandomizedDelaySec=1800. Затем systemctl daemon-reload, systemctl enable --now zfs-scrub@tank.timer. Persistent=true нужен, чтобы пропущенный из-за выключения сервера запуск выполнился при следующей загрузке, а RandomizedDelaySec разносит проверки на нескольких серверах, чтобы они не били по дискам одновременно.

Вариант через cron занимает одну строку: 0 3 1 * * /sbin/zpool scrub tank. Минус cron в том, что пропущенное задание не выполняется, а вывод команды уходит в почту root. После любого автоматического запуска статус всё равно надо читать: zpool status tank -x покажет только пулы с проблемами.

Scrub в Btrfs: команды, отличия и подводные камни

Btrfs считает контрольную сумму для каждого блока данных и метаданных, а алгоритм задаётся при создании файловой системы: mkfs.btrfs -c xxhash. Доступны crc32c (по умолчанию), xxhash, sha256 и blake2. Суммы хранятся в отдельном дереве csum, поэтому проверка не требует чтения самих метаданных файлов.

Scrub обходит все блоки с контрольными суммами и при несовпадении пытается получить целую копию из профиля избыточности: RAID1, RAID10, RAID1C3, DUP. В профиле single восстанавливать нечего, и scrub работает как детектор повреждений. Проверку можно запускать на смонтированной файловой системе, прерывать и продолжать с места остановки.

Запуск в фоне: btrfs scrub start /mnt
Запуск с ожиданием в терминале: btrfs scrub start -B /mnt
Только чтение, без попыток ремонта: btrfs scrub start -r /mnt
Статус: btrfs scrub status /mnt
Отмена: btrfs scrub cancel /mnt
Продолжение: btrfs scrub resume /mnt
Ограничение скорости в операциях ввода-вывода: btrfs scrub limit /mnt

Команды pause в btrfs нет: если проверку нужно остановить, используйте cancel, а позже resume, проверка продолжится с достигнутого места. Параллельно с scrub не стоит запускать balance: обе операции читают и перезаписывают большие объёмы, и вместе они кладут дисковую подсистему.

Запуск и мониторинг scrub в Btrfs: команды и статус

Статус читается командой btrfs scrub status /mnt и выглядит примерно так: scrub status for 8f3c1a2e-... , scrub started at Sun Sep 6 02:00:11 2026 and finished after 01:12:44, total bytes scrubbed: 1.20TiB with 0 errors. Ниже идёт строка Error summary: read=0 super=0 csum=0 verify=0 corrected=0 uncorrectable=0 no_csum=0. Значения расшифровываются так:

csum - несовпадение контрольных сумм, самое частое следствие bit rot и сбоев памяти.
corrected - повреждённые блоки, успешно восстановленные из второй копии. Ненулевое значение это сигнал, а не катастрофа: смотрите SMART и dmesg.
uncorrectable - блоки, которые восстановить не удалось. Данные в этих блоках потеряны, нужен бэкап.
read, super, verify - ошибки ввода-вывода, повреждения суперблока и расхождения при проверке копий метаданных.

Накопленную статистику по устройству показывает btrfs device stats /mnt: счётчики read_errors, write_errors, flush_errors, corruption_errors, generation_errors. Сбрасывать их, чтобы обнулить историю, можно командой btrfs device stats -z /mnt. Счётчики не обнуляются после успешного scrub, поэтому их рост между проверками важнее абсолютных значений.

Настройка расписания scrub в Btrfs через systemd timer

В Debian и Ubuntu пакет btrfs-progs содержит шаблоны btrfs-scrub@.service и btrfs-scrub@.timer. Команда systemctl enable --now btrfs-scrub@-.timer включает проверку для всех подключённых файловых систем Btrfs, а systemctl start btrfs-scrub@mnt-data.timer настраивает расписание для конкретной точки монтирования. В openSUSE ту же задачу решает штатный btrfsmaintenance с профилями daily, weekly и monthly.

Свой таймер собирается так же, как для ZFS: юнит с ExecStart=/usr/bin/btrfs scrub start -B /mnt и таймер с OnCalendar=monthly и Persistent=true. Через cron строка выглядит как 0 4 * * 0 /usr/bin/btrfs scrub start -B /mnt для еженедельного запуска в ночь с субботы на воскресенье.

Важное предупреждение: на деградировавшем массиве Btrfs scrub не запускают. Сначала замените сбойное устройство командой btrfs replace, дождитесь завершения, и только потом проверяйте целостность. Проверка на массиве без запаса избыточности добавляет нагрузку на последний живой диск и не может ничего починить.

Ограничения Btrfs RAID5/6 и почему scrub не спасёт

В RAID5 и RAID6 у Btrfs есть проблема write hole. Чётность, данные и метаданные записываются в разные моменты, и при внезапном отключении питания или крахе ядра состояние чётности может остаться несогласованным с данными. Долгое время scrub в Btrfs сверял только контрольные суммы данных и метаданных, а расхождения в чётности оставались невидимыми; проверка чётности в scrub появилась лишь в свежих версиях ядра.

Практические следствия: RAID5/6 у Btrfs не рекомендуют для продакшена с критичными данными, профиль RAID5/6 применяют только к данным, а метаданные размещают с зеркалированием (например, mkfs.btrfs -d raid5 -m raid1c3). Для массивов из 3-4 дисков предпочтительнее RAID1 или RAID10 у Btrfs, а для больших конфигураций - ZFS с RAID-Z1, RAID-Z2 или RAID-Z3, где чётность покрыта контрольными суммами и scrub действительно может её исправить.

Если Btrfs RAID5/6 уже работает, минимальный набор мер такой: ежедневный dmesg -T | grep -i btrfs на предмет btrfs checksum mismatch и I/O error, регулярный scrub, внешний бэкап и план миграции на зеркальные профили. Ошибки чётности при этом стоит считать признаком того, что массив нужно пересобирать, а не чинить.

Аппаратный RAID: что на самом деле проверяют patrol read и consistency check

RAID-контроллер видит диски как набор секторов и оперирует блоками и чётностью. Контрольных сумм файловой системы у него нет, поэтому проверка целостности данных сводится к двум механизмам: patrol read и consistency check. Плюс есть background initialization, которая раскладывает данные по дискам после создания тома без полного пересчёта чётности.

Patrol read vs consistency check: в чём разница

Patrol read читает сектора всех дисков массива, чтобы выявить те, которые физически не отдаются. Он ничего не записывает и не исправляет, только наполняет счётчик media errors и заранее перераспределяет проблемные сектора. На контроллерах LSI и Broadcom patrol read по умолчанию может быть в режиме auto: проход выполняется в простое, чтобы не мешать рабочей нагрузке.

Consistency check (CC, check consistency) проверяет чётность и, при нахождении расхождений, перезаписывает её. Здесь и кроется риск. Если на диске есть нечитаемый сектор, контроллер соберёт отсутствующие данные из чётности остальных дисков и запишет результат. При наличии других ошибок чтения или устаревшей чётности это может привести к записи некорректных данных поверх корректных. Для RAID5 опасность выше всего: массив без запаса избыточности при ошибке чтения во время CC теряет том.

Практическое правило: patrol read запускают регулярно, consistency check - по расписанию, но только после свежего бэкапа и только на массиве в состоянии Optimal. На деградировавшем томе consistency check не запускают ни в каком виде.

Как настроить и мониторить проверки на аппаратном RAID

Для контроллеров LSI, Broadcom и их OEM-версий используется storcli:

Включить patrol read: storcli /c0 set patrolread=on
Посмотреть настройки и статус: storcli /c0 show patrolread
Запустить проверку целостности: storcli /c0 start cc
Показать статус проверки: storcli /c0 show cc
Состояние всех дисков с ошибками: storcli /c0/eall/sall show all

В выводе по каждому диску смотрите поля Media Error Count, Other Error Count и Predictive Failure Count. Рост Media Error Count означает сбойные сектора, Predictive Failure Count это предупреждение о скором отказе. Устаревшие системы используют MegaCli с ключом -LDCheck -Lall -aALL для запуска проверки логических дисков.

Для Adaptec и Microsemi команды даёт утилита arcconf: картина по контроллеру и дискам выводится через arcconf getconfig 1, а проверка логического диска запускается как arcconf task start 1 logicaldrive 0 verify, с исправлением найденных расхождений - arcconf task start 1 logicaldrive 0 verifyfix. Параметр patrolread удобнее настраивать в графической консоли maxView Storage Manager, где для него есть отдельный переключатель.

SMART за аппаратным RAID напрямую не читается, потому что физические диски не подключены к операционной системе. Для LSI используйте ключ megaraid с номером диска: smartctl -d megaraid,5 -a /dev/sda. Для Adaptec работает -d aacraid,H,L,ID. Без этого smartctl покажет атрибуты самого RAID-тома, а не диска.

Если вместо аппаратного RAID используется программный массив mdadm, проверка встроена в ядро: echo check > /sys/block/md0/md/sync_action запускает сверку копий и чётности, результат читается из /sys/block/md0/md/mismatch_cnt, а исправление выполняется записью repair в тот же sync_action. Синтаксис и типовые сценарии разобраны в руководстве по программным RAID-массивам на Linux.

Почему аппаратный RAID не гарантирует целостность данных

RAID даёт отказоустойчивость, но не целостность. Контроллер проверяет, что сектор читается, и что чётность согласована с данными, но не знает, те ли это байты, которые записала файловая система. Если поверх тома работает ext4 или XFS без контрольных сумм пользовательских данных, подмена байтов пройдёт незамеченной и всплывёт при чтении файла.

Обратная конфигурация тоже проблемная. Если положить ZFS поверх аппаратного RAID, ZFS увидит один диск и обнаружит несовпадение контрольной суммы при чтении, но починить блок не сможет: избыточность находится внутри контроллера и недоступна файловой системе. В zpool status появятся ошибки CKSUM, а восстановить данные придётся из бэкапа. Правильный вариант для ZFS и Btrfs: HBA-контроллер в режиме IT или JBOD, каждому диску отдельное устройство, избыточность строит файловая система.

Есть и аппаратные механизмы защиты. T10 PI (DIF) добавляет к каждому сектору служебное поле с контрольной суммой и позволяет проверять данные по всей цепочке от приложения до носителя, но для этого нужна поддержка со стороны дисков, контроллера и стека операционной системы, а драйверная поддержка в Linux ограничена. BBU или NVRAM на контроллере защищает от write hole при потере питания, но никак не влияет на тихие повреждения. В программном стеке Linux ту же задачу решают dm-integrity поверх RAID и журнал mdadm для RAID5/6, который записывает намерения перед изменением чётности.

Метрики и мониторинг: что смотреть после scrub

Смысл проверки в том, чтобы вовремя заметить деградацию. Разовое чтение статуса мало что даёт, нужны регулярные замеры и пороги срабатывания.

Ключевые метрики ZFS после scrub

Строка scan в zpool status: значение repaired в байтах и число errors. repaired больше нуля означает, что избыточность спасла данные, и это повод проверить диски.
Столбцы READ, WRITE, CKSUM в таблице пула. Любые ненулевые значения требуют разбора через zpool status -v, где перечислены конкретные файлы и объекты.
События пула: zpool events -v показывает историю scrub, ошибок и переключений состояния, что удобно для сопоставления с журналом железа.
SMART: атрибуты 5 Reallocated_Sector_Ct, 187 Reported_Uncorrect, 197 Current_Pending_Sector, 198 Offline_Uncorrectable, 199 UDMA_CRC_Error_Count.

Пороги для ZFS простые. Ненулевое Current_Pending_Sector означает, что диск уже не может прочитать сектор: данные с него надо снять, а диск заменить. Рост Reallocated_Sector_Ct между проверками означает, что запас резервных секторов расходуется. Ненулевое Offline_Uncorrectable подтверждает нечитаемые сектора. Растущий UDMA_CRC_Error_Count чаще указывает на кабель или бэкплейн, а не на диск. Оповещения удобно получать через ZED: в zed.rc задаётся адрес получателя, а сам демон вызывает zpool status и рассылает уведомления при ошибках, деградации и завершении scrub. Готовые дашборды и экспортеры описаны в материале про мониторинг систем хранения.

Ключевые метрики Btrfs после scrub

btrfs scrub status: поля corrected и uncorrectable в Error summary.
btrfs device stats: пять счётчиков ошибок по каждому устройству.
dmesg -T | grep -i btrfs: сообщения checksum mismatch, parent transid verify failed, I/O error.
SMART через smartctl -a /dev/sdX, поскольку Btrfs работает с дисками напрямую.

Порог для uncorrectable один: ноль. Любое ненулевое значение означает потерю данных в этих блоках, и файлы нужно восстанавливать из бэкапа, а затем разбираться с причиной. Ненулевое corrected требует проверки SMART и оперативной памяти сервера: тихие ошибки часто приходят из сбойного DIMM в кэше записи. Счётчик generation_errors указывает на расхождение поколений метаданных, что типично для сбоев питания без корректного отключения. Настроить регулярный сбор счётчиков проще всего через systemd timer с btrfs device stats и алерт в smartd или Zabbix.

Ключевые метрики аппаратного RAID

Media Error Count и Other Error Count по каждому диску: storcli /c0/eall/sall show all
Predictive Failure Count и состояние диска: storcli /c0/eall/sall show all | grep -i failure
Состояние тома и идущие фоновые операции: storcli /c0 show all
Счётчики контроллера у Adaptec: arcconf getconfig 1

Логика реагирования: Predictive Failure это замена диска в плановом порядке, рост Media Error Count означает ускоренную замену, а расхождение между числом ошибок на одном диске и остальными указывает на конкретное устройство. Алерты настраивают через веб-интерфейс контроллера, SNMP-ловушки или систему мониторинга, которая периодически вызывает storcli и разбирает вывод. Хранить историю этих счётчиков обязательно: без неё невозможно отличить старую ошибку от новой.

Если своего второго массива нет, реплику метрик или резервные копии удобно держать вне площадки: например, Timeweb Cloud даёт серверы, объектное хранилище и базы данных, на которых можно поднять вторую копию данных и внешний узел мониторинга, не покупая железо.

Типичные ошибки администраторов при работе со scrub

Большая часть инцидентов с потерей данных связана не с отсутствием scrub, а с двумя конкретными ошибками в порядке действий и в реакции на результат.

Почему нельзя запускать scrub на деградировавшем массиве

При выходе диска из строя массив продолжает работать за счёт избыточности, но запас прочности уже израсходован. Scrub читает весь объём данных, то есть создаёт максимальную нагрузку именно на те диски, которые остались. На RAID-Z1 с одним выбывшим диском уцелевшие накопители работают без страховки: ошибка чтения на любом из них означает потерю пула целиком. На зеркале из двух дисков та же логика: второй отказ убивает данные.

Правильный порядок действий такой:

Зафиксировать состояние: zpool status -v или btrfs scrub status, проверить ошибки и состояние дисков.
Заменить сбойный диск и дождаться полного resilver или btrfs replace.
Убедиться, что пул вернулся в состояние ONLINE и ошибок нет.
Запустить scrub и проанализировать результат.

ZFS защищает от части таких ситуаций: запуск scrub во время resilver отклоняется. Btrfs мягче и позволит запустить проверку, поэтому дисциплина здесь нужна со стороны администратора. На аппаратном RAID запрет тот же: никакого consistency check при состоянии Degraded, поскольку перезапись чётности на деградировавшем томе может уничтожить единственные валидные данные.

Что делать при обнаружении ошибок checksum

Вторая распространённая ошибка - увидеть ненулевые CKSUM или csum, очистить счётчики и жить дальше. Счётчик ошибок в ZFS держится до команды zpool clear, и он не является чем-то косметическим: он показывает, что данные на дисках уже расходились с контрольными суммами. Повторение ситуации означает, что причина не устранена, а следующая ошибка может попасть в блок, для которого целой копии не останется.

Получите список пострадавших объектов: zpool status -v для ZFS или dmesg с btrfs checksum mismatch для Btrfs.
Отделите исправленные ошибки от неустранимых: repaired больше нуля при нулевом errors это вылеченные повреждения, ненулевое uncorrectable означает потерю данных.
Проверьте SMART всех дисков пула и оперативную память при повторяющихся csum-ошибках на разных дисках.
Восстановите повреждённые файлы из бэкапа, если валидной копии нет.
Замените диск при росте переназначенных или ожидающих секторов, затем дождитесь resilver.
Прогоните scrub повторно, чтобы убедиться, что новых ошибок нет.
Обнулите счётчики командой zpool clear или btrfs device stats -z только после того, как причина найдена и устранена.

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

Автоматизировать разбор больших логов и результатов проверок помогает LLM: AiTunnel даёт доступ к моделям GPT, Gemini и Claude через единый API с оплатой в рублях, и на нём удобно собрать сценарий, который читает вывод zpool status или dmesg, вытаскивает повторяющиеся ошибки и пишет краткое резюме в дежурный чат.

Как выбрать периодичность scrub и снизить влияние на производительность

Интервал проверки задаёт окно, в течение которого повреждённый блок может остаться незамеченным, и определяет, успеете ли вы починить его, пока цела избыточность. Второй фактор - стоимость проверки: она занимает диски на часы и дни, а значит влияет на отзывчивость сервисов.

Ограничение нагрузки scrub на рабочую систему

Scrub читает диски на максимально возможной скорости, поэтому запускать его в часы пиковой нагрузки не стоит. Дополнительные рычаги зависят от платформы.

ZFS: увеличить zfs_scrub_delay (по умолчанию 4) в 5-10 раз, проверить zfs_scan_min_time_ms и zfs_top_maxinflight. Проверку можно приостановить командой zpool scrub -p и возобновить повторным запуском.
Btrfs: задать предел в операциях ввода-вывода командой btrfs scrub limit, остановить через btrfs scrub cancel и продолжить через btrfs scrub resume. ionice влияет ограниченно, так как чтение выполняют ядерные потоки.
Аппаратный RAID: снизить долю времени на patrol read в свойствах контроллера или в графической консоли, вынести consistency check в окно обслуживания.
Общий приём: разнести запуски по серверам через случайную задержку, как в systemd-таймере с RandomizedDelaySec, чтобы проверки не совпадали по времени.

Оценить время заранее можно по простой арифметике. Пул на 100 ТБ при суммарной скорости чтения около 1 ГБ/с проверяется примерно за 28 часов, при 500 МБ/с - почти за двое суток. Фрагментация, мелкие блоки, активная запись и медленные диски увеличивают это время в 1,5-2 раза. Для расчёта используйте фактические значения из строки scan в zpool status после первого запуска: она показывает скорость, с которой пул реально читается.

Минимальный рабочий набор для любого массива выглядит так: регулярный scrub по расписанию, ежедневный сбор метрик и SMART, алерт на деградацию и на рост счётчиков ошибок, свежий бэкап и запрет на запуск проверок при потере избыточности. Настроить эти четыре элемента проще за один вечер, чем восстанавливать данные после отказа второго диска.