ZFS scrub и resilver: полное руководство по контролю целостности пула

Целостность ZFS держится на контрольных суммах: каждый блок данных и метаданных получает checksum, который система сверяет при чтении. Пока блок лежит на диске и не читается, ошибка в нём незаметна. Команда zpool scrub tank заставляет ZFS прочитать весь пул, проверить каждую контрольную сумму и восстановить повреждённый блок из избыточности, если пул собран на mirror или RAIDZ.

Resilver стартует сам, когда в пул добавляют новый или заменённый диск: ZFS копирует на него данные с остальных устройств. Scrub вы планируете, resilver приходит с событием. Оба процесса читают весь объём пула, поэтому одновременно их не запускают: resilver получает приоритет, а scrub приостанавливается до его завершения.

Дальше по порядку: запуск и расписание scrub, разбор вывода zpool status -v, замена диска через zpool replace, SMART-тесты через smartctl, действия при DEGRADED и готовый скрипт мониторинга с алертами от zed.

Что такое ZFS scrub и зачем он нужен

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

Пул на mirror или RAIDZ2 восстанавливает повреждённый блок из копии и перезаписывает его корректной версией. Механизм называется self-healing. Когда избыточности не хватает, ZFS помечает файл повреждённым и выводит его в отчёте как permanent error.

Частота запуска: раз в 1-4 недели для активных данных, раз в квартал для архивов. ZFS сама scrub не планирует, расписание настраивает администратор через cron, systemd или панель TrueNAS. Scrub дополняет SMART: диск проходит self-test, но при этом отдаёт блоки с неверной контрольной суммой.

Чем scrub отличается от resilver

• Scrub проверяет существующие блоки, resilver переносит данные на новый или заменённый диск.
• Scrub запускается вручную или по расписанию, resilver стартует автоматически после zpool replace или zpool attach.
• Scrub прерывается командой zpool scrub -s и повторяется позже. Прерывать resilver нежелательно: пока он идёт, пул работает без одного диска избыточности.
• При совпадении по времени ZFS приоритизирует resilver и приостанавливает scrub, а не наоборот.

Оба процесса видны в строке scan вывода zpool status: там указано, сколько данных просканировано, сколько восстановлено и когда операция завершилась.

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

Scrub читает диск почти на максимальной скорости. Одиночный HDD отдаёт 120-180 МБ/с, RAIDZ2 из восьми дисков выдаёт суммарно несколько ГБ/с, но растёт очередь запросов и время отклика. Для баз данных и виртуальных машин scrub в рабочие часы заметен.

Что снижает влияние на боевую нагрузку:

• zfs_scrub_delay в /sys/module/zfs/parameters/: пауза после каждого I/O scrub. По умолчанию 0, рост значения замедляет проверку и разгружает диски.
• zfs_scan_min_time_ms: минимум миллисекунд на сканирование в каждой транзакционной группе, по умолчанию 1000. В старых сборках параметр назывался zfs_resilver_min_time_ms.
• Расписание в окно низкой нагрузки, обычно 02:00-05:00.

cat /sys/module/zfs/parameters/zfs_scrub_delay
echo 10 > /sys/module/zfs/parameters/zfs_scrub_delay

Значение через /sys сбрасывается после перезагрузки. Постоянная настройка задаётся в /etc/modprobe.d/zfs.conf строкой options zfs zfs_scrub_delay=10.

Как запустить и настроить scrub в ZFS

zpool scrub tank          # старт проверки
zpool status tank         # прогресс и результат
zpool scrub -s tank       # остановка

Перед запуском проверьте состояние пула: команда zpool status -x выводит только проблемные пулы и молчит, если всё в порядке. При DEGRADED сначала устраните причину деградации, иначе scrub потратит ресурс на чтение, которое не сможет починить блоки.

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

Файл /etc/cron.d/zfs-scrub с еженедельным запуском по воскресеньям в 03:00:

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
0 3 * * 0 root /sbin/zpool scrub tank

Вариант на systemd, юнит /etc/systemd/system/zfs-scrub@.service:

[Unit]
Description=ZFS scrub for pool %i
[Service]
Type=oneshot
ExecStart=/sbin/zpool scrub %i

Таймер /etc/systemd/system/zfs-scrub@.timer:

[Unit]
Description=Weekly scrub for pool %i
[Timer]
OnCalendar=Sun 03:00
Persistent=true
[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now zfs-scrub@tank.timer
systemctl list-timers 'zfs-scrub*'

Persistent=true добивает пропущенный запуск после простоя сервера. В Debian и Ubuntu пакет zfsutils-linux поставляет готовые юниты zfs-scrub-weekly@.timer и zfs-scrub-monthly@.timer, их включают одной командой без правки файлов. В TrueNAS расписание задаётся в интерфейсе: Data Protection, Scrub Tasks. Практика сервисного обслуживания пулов в TrueNAS, включая планирование и замену дисков, собрана в руководстве Проактивное обслуживание ZFS в TrueNAS: мониторинг, скраб и замена дисков.

Проверка результата scrub

После завершения zpool status -v показывает строку scan:

scan: scrub repaired 0B in 01:12:33 with 0 errors on Sun Sep 6 04:12:33 2026

• repaired 0B и 0 errors: пул здоров, ошибок не найдено.
• repaired больше нуля: ZFS нашла и починила блоки из избыточности. Смотрите, на каких устройствах росли счётчики CKSUM.
• Строка errors: Permanent errors: восстановить данные не удалось, нужен бэкап.

Детали ищутся в истории событий: zpool events -v | grep -i checksum. Если после scrub ошибки на одном диске появляются снова, планируйте замену. Диск отдаёт блоки, но теряет их содержимое.

Как читать zpool status -v: расшифровка ошибок и статусов

zpool status -v tank

Вывод строится из четырёх частей: имя пула и его состояние, блок status с рекомендацией, строка scan, таблица устройств и итоговая строка errors. Разберём деградированный пример:

  pool: tank
 state: DEGRADED
status: One or more devices could not be used because the label is missing
        or invalid. Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 01:12:33 with 0 errors on Sun Sep 6 04:12:33 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     FAULTED     12     0     4  too many errors
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0

errors: No known data errors

Что означают ошибки CKSUM, READ и WRITE

• CKSUM: контрольная сумма блока не совпала. ZFS читает копию с другого диска, чинит блок и перезаписывает его. Причины: битый сектор, сбойный кабель, ошибки контроллера или памяти.
• READ: устройство не смогло прочитать блок и вернуло ошибку ввода-вывода.
• WRITE: запись не прошла. Часто указывает на кабель, порт HBA или питание, а не на сам накопитель.

Счётчики в столбцах READ, WRITE и CKSUM накапливаются с момента последнего zpool clear. Растущий CKSUM на одном устройстве при нулях на остальных означает проблему с диском или с трактом передачи данных.

Пошаговая проверка пула сразу после создания, с разбором строки scan и первых признаков деградации, описана в материале Проверка и обслуживание ZFS-пула после создания.

Статусы пула: ONLINE, DEGRADED, FAULTED, UNAVAIL

• ONLINE: все устройства на месте, избыточность полная.
• DEGRADED: пул работает, но избыточность потеряна. Второй отказ приведёт к потере данных, замена диска срочная.
• FAULTED: пул или vdev недоступен, данные читаются из бэкапа или снапшотов.
• UNAVAIL: пул не открыть, часть устройств отсутствует.

У отдельных дисков встречаются ещё два состояния: OFFLINE (выведен командой zpool offline) и REMOVED (диск физически извлечён). При горячем подключении REMOVED обрабатывает ZFS сама, ручных действий не требуется.

Замена диска в ZFS пуле и процесс resilver

Пошаговая инструкция замены диска

1. zpool status -v tank                     # найти проблемный диск
2. zpool offline tank /dev/sdb              # если диск ещё отвечает
3. Физическая замена диска в корзине
4. zpool replace tank /dev/sdb /dev/sdd     # замена на другой слот
5. zpool status tank                        # следить за resilver
6. zpool clear tank                         # сброс счётчиков
7. smartctl -a /dev/sdd                     # проверка нового диска

Когда новый диск встал в тот же слот под старым именем, хватает одной команды zpool replace tank /dev/sdb. Если имя изменилось, указывайте два аргумента: старое и новое устройство. Надёжнее брать идентификатор из вывода zpool status -g: GUID не зависит от порядка, в котором ядро присвоило имена /dev/sdX.

Для горячей замены добавьте резервный диск заранее, а свойство autoreplace=on позволит ZFS подхватить его автоматически:

zpool add tank spare /dev/sdf
zpool set autoreplace=on tank

Если новый накопитель крупнее старого, включите autoexpand=on: после завершения resilver пул расширится до полного объёма диска без пересоздания.

Мониторинг прогресса resilver и оценка времени

Строка scan во время восстановления выглядит так:

  scan: resilver in progress since Sun Sep 6 03:14:22 2026
        412G scanned at 1.02G/s, 132G issued at 336M/s
        0.00% done, 00:26:41 to go

Ориентиры по времени: 1 ТБ данных на одиночном HDD при 150 МБ/с восстанавливается примерно за 2 часа. В RAIDZ2 из шести дисков те же 1 ТБ идут 4-8 часов, потому что головки постоянно переключаются между чтением и записью. SSD сокращает срок в разы, но упирается в шину и возможности контроллера.

Поток операций удобно наблюдать через zpool iostat -v tank 5. Признаки проблемы: прогресс не меняется десятки минут, в dmesg сыплются ошибки ata или sense key, счётчик CKSUM растёт. Прерывать resilver не стоит: при зависании проверяйте железо и кабели, а не пытайтесь отменить операцию.

Параметр zfs_resilver_delay (по умолчанию 2 тика) добавляет паузу после каждого I/O восстановления: рост значения снижает нагрузку на боевые задачи и растягивает время. zfs_scan_min_time_ms задаёт минимум времени на сканирование в транзакции. Так вы балансируете между скоростью восстановления избыточности и отзывчивостью сервисов.

Мониторинг ошибок и настройка уведомлений

Проверять zpool status вручную раз в неделю недостаточно: деградация в три часа ночи должна будить алерт, а не ждать утреннего обхода. События ZFS отправляет демон zed.

Настройка zed для автоматических уведомлений

Правки в /etc/zfs/zed.d/zed.rc:

ZED_EMAIL_ADDR='admin@example.com'
ZED_EMAIL_OPTS='-s /usr/sbin/sendmail -t'
ZED_NOTIFY_VERBOSE=1
ZED_NOTIFY_INTERVAL_SECS=3600

systemctl restart zed
systemctl status zed
journalctl -u zed -n 50

ZED_NOTIFY_VERBOSE=1 включает письма обо всех событиях, включая старт scrub. Без него приходят только ошибки. Проверку делайте на тестовом стенде: извлеките диск из корзины, убедитесь, что письмо дошло, верните накопитель и выполните zpool online tank /dev/sdX.

В TrueNAS почта настраивается в System, Alert Services, там же включаются уведомления о деградации пула и проблемах SMART. Расширенные сценарии с webhook, Telegram и фильтрами собраны в статье Alerting в TrueNAS: полное руководство по настройке уведомлений для мониторинга дисков и ZFS.

Использование zpool events для диагностики

zpool events -v
zpool events -v | grep -i 'checksum\|io_error'
zpool events -c          # очистить историю событий

История событий помогает при разборе инцидентов: видно, когда появилась первая ошибка чтения, когда стартовал scrub, когда vdev вернулся в строй. Основные имена событий: checksum, io_error, scrub_start, scrub_finish, resilver_start, vdev_clear. Сохраняйте вывод перед очисткой, это доказательство для гарантийного обращения к поставщику дисков.

SMART-проверки дисков в ZFS

SMART показывает состояние накопителя на аппаратном уровне. ZFS видит только следствие: ошибки чтения и несовпадение контрольных сумм. Комбинация обоих источников даёт полную картину.

smartctl -a /dev/sda              # атрибуты и информация
smartctl -H /dev/sda              # итоговый health status
smartctl -t short /dev/sda        # короткий тест, около 2 минут
smartctl -t long /dev/sda         # полный тест, зависит от объёма
smartctl -l selftest /dev/sda     # результаты тестов

Короткий тест прогоняется ежедневно или еженедельно, длинный на 8 ТБ идёт 10-15 часов и запускается в выходные. Ключевые атрибуты, за которыми стоит следить в ZFS-пуле:

Растущий UDMA_CRC при нулевых ошибках чтения часто даёт CKSUM в ZFS: данные доходят с искажением, хотя сам накопитель исправен. В такой ситуации меняют кабель и переносят диск в другой порт, прежде чем покупать новый.

Автоматизация SMART-тестов

/etc/smartd.conf
/dev/sda -a -o on -S on -s (S/../.././02|L/../../6/03) -m admin@example.com
DEVICESCAN -a -o on -S on -m admin@example.com

systemctl enable --now smartd
systemctl status smartd

Расписание S/../.././02 запускает короткий тест ежедневно в 02:00, L/../../6/03 запускает длинный по субботам в 03:00. Директива -o on включает автоматическое офлайн-сканирование, -S on сохраняет атрибуты при переходе диска в сон, -m задаёт адрес для писем. В TrueNAS тесты настраиваются в Storage, Disks, S.M.A.R.T. Tests, результаты видны в том же окне.

Действия при degraded pool и ошибках

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

zpool status -v tank
zpool online tank /dev/sdb      # вернуть диск после временного сбоя
zpool offline tank /dev/sdb     # вывести диск на обслуживание
zpool clear tank                # сбросить счётчики ошибок

Как использовать zpool clear и zpool online/offline

• zpool online возвращает устройство, которое ZFS исключила после краткого сбоя питания или кабеля. Сразу после команды запускается resilver.
• zpool offline выводит диск из работы, не удаляя его из конфигурации. В RAIDZ это снижает избыточность на один диск, держать устройство в OFFLINE долго нельзя.
• zpool clear обнуляет счётчики READ, WRITE, CKSUM и список ошибок. Железо команда не лечит: если причина не устранена, ошибки вернутся в течение часов.

Что делать при permanent errors

Строка errors: Permanent errors означает, что ZFS не может восстановить блоки даже с избыточностью. Типовые сценарии: пул на одиночном диске, потеря двух накопителей в RAIDZ1, повреждение метаданных. Действия по шагам:

1. Скопируйте уцелевшие данные на другой носитель, прежде чем что-либо менять в пуле.
2. Получите список пострадавших файлов: zpool status -v tank покажет их после строки permanent errors.
3. Восстановите файлы из бэкапа или снапшота: zfs list -t snapshot, затем zfs send и zfs receive либо доступ через каталог .zfs/snapshot.
4. Не выполняйте zpool clear до разбора причины, иначе потеряете историю ошибок.
5. Если бэкапа нет, остановите запись на пул и обратитесь в сервис по восстановлению данных: самостоятельные эксперименты снижают шансы на успех.

Методы диагностики и починки ZFS, включая работу с повреждёнными метаданными пула, разобраны в руководстве Восстановление ZFS в TrueNAS и Proxmox: диагностика ошибок, scrub, resilver и zdb.

Сравнение стратегий контроля целостности в ZFS

Режим обслуживания зависит от типа данных и допустимого простоя. Таблица ниже задаёт базовые ориентиры по частоте операций.

Вторая таблица помогает быстро сопоставить симптом с причиной и действием.

Для продакшн-систем добавьте hot spare и отдельный пул под бэкапы: resilver на большом RAIDZ2 занимает часы, и всё это время пул держит пониженную избыточность.

Best practices и автоматизация для ZFS

Проверять состояние удобно скриптом, который сам себя запускает по cron и пишет письмо при отклонении.

Готовый скрипт для мониторинга ZFS

#!/bin/bash
POOL='tank'
MAIL='admin@example.com'

if ! zpool status -x "$POOL" | grep -q 'all pools are healthy'; then
  zpool status -v "$POOL" | mail -s "ZFS ALERT: $POOL" "$MAIL"
fi

for disk in /dev/sd?; do
  if ! smartctl -H "$disk" | grep -q 'PASSED'; then
    echo "SMART problem on $disk" | mail -s "SMART ALERT: $disk" "$MAIL"
  fi
done

chmod +x /usr/local/bin/zfs-check.sh
crontab -e
0 6 * * * /usr/local/bin/zfs-check.sh

Скрипт стоит прогнать на стенде до постановки в cron: поднимите тестовый пул, добавьте и выдерните виртуальный диск, проверьте, что письмо уходит. Облачный сервер с несколькими дисками для такого стенда поднимается за минуты, например в Timeweb Cloud: удобно отработать replace, resilver и restore, не рискуя боевыми данными.

Особенности TrueNAS

В TrueNAS большая часть рутины закрыта интерфейсом: Scrub Tasks в Data Protection, S.M.A.R.T. Tests в Storage, Disks, Alert Services в System. Периодические снапшоты настраиваются в Data Protection, Periodic Snapshot Tasks. Уровень логирования и историю проверок смотрите в System, Logs. Управляемые параметры модуля ZFS задаются через System, Advanced, Sysctl: там приживаются zfs_scrub_delay и zfs_scan_min_time_ms.

Метрики пулов, задержки дисков и состояние ARC удобно выводить в Grafana. Готовые дашборды и правила алертинга описаны в руководстве Мониторинг ZFS: ключевые метрики и настройка оповещений.

Чек-лист администратора ZFS

• Настройте scrub по расписанию: cron, systemd timer или Scrub Tasks в TrueNAS.
• Включите zed с отправкой писем и проверьте доставку алертов на тестовом событии.
• Проводите короткий SMART-тест ежедневно или еженедельно, длинный - раз в месяц.
• Смотрите zpool status -v и zpool events -v минимум раз в неделю.
• Держите hot spare для критичных пулов и включите autoreplace.
• Проверяйте бэкапы восстановлением, а не наличием файла на ленте.
• Задокументируйте схему пула, имена дисков и GUID устройств.
• Реагируйте на DEGRADED в тот же день: запас избыточности уже израсходован.
• Тестируйте zpool replace и восстановление из снапшота на стенде.
• Держите параметры zfs_scrub_delay и zfs_resilver_delay под контролем, если пул обслуживает боевую нагрузку.