ZFS pool degraded: заменить диск по правилам, не перепутав vdev

Короткий ответ

zpool status rpool — источник истины, не «какой диск мигает в корзине». Запоминаете vdev по /dev/disk/by-id или GUID, подтверждаете SMART, вставляете новый диск того же класса, затем zpool replace. Не делайте replace первого попавшегося sdc и не zpool clear, чтобы спрятать ошибки на единственной копии данных.

Resilver сам по себе — нагрузка. На деградированном пуле без запасного зеркала форсировать scrub/resilver «чтобы быстрее» можно добить второй диск.

Симптомы и как отличить

Типичная картина:

• zpool status : DEGRADED, один leaf FAULTED/UNAVAIL;
• GUI Datacenter → Disks/ZFS с ошибками read/write/cksum;
• гости на rpool живы, но IO нестабилен;
• после ребута пул встал degraded, не «пропал».

Отличия:

Возможные причины

1. Умер диск в mirror/raidz.
2. Плохой кабель, backplane, слот — диск «пропадает».
3. Неверный диск извлекли руками.
4. После замены контроллера имена sdX поехали, ZFS ещё держит GUID.
5. Заполнился пул, плюс ошибки — путают с ENOSPC.
6. Несовместимый spare, который не должен был сесть в этот vdev.

Диагностика

pveversion
zpool status -v rpool
zpool list rpool
ls -l /dev/disk/by-id
smartctl -a /dev/disk/by-id/ata-...

Скопируйте id неисправного leaf из zpool status, не букву sd. Сверьте физическую корзину по WWN/серийнику в BMC.

zpool get all rpool | grep -E 'health|size|fragmentation'
dmesg | grep -iE 'mpt|ahci|nvme|I/O error' | tail

Топология: mirror из двух — можно replace одного. raidz1 — тоже один. stripe без избыточности — replace не вернёт данные, нужен backup.

Решение

Сценарий A. Mirror/raidz, диск FAULTED, новый диск вставлен

Оффлайн не всегда обязателен, если диск уже выпал. Идентификаторы подставьте свои:

zpool replace rpool \
  /dev/disk/by-id/ata-OLD_SERIAL \
  /dev/disk/by-id/ata-NEW_SERIAL
zpool status rpool

Дождитесь resilver. Не выдёргивайте второй диск «проверить». Не запускайте параллельно тяжёлый scrub+vzdump+migrate на этом пуле без нужды.

Сценарий B. Диск UNAVAIL, физически на месте

Пересев, кабель, порт. Если SMART чистый и ошибки исчезли после кабеля — не торопитесь replace. Если ошибки вернулись — диск.

Сценарий C. Ошиблись слотом и вытащили здоровый

Верните диск сразу. zpool status. Не replace «на всякий случай» третьим диском, пока не поняли, кто FAULTED.

Сценарий D. Нет избыточности (stripe)

Не replace как восстановление. Восстанавливайте VM из PBS/vzdump. Replace здесь не воскрешает блоки.

Сценарий E. zpool clear

Только когда заменили причину (кабель) и хотите сбросить счётчики на здоровом пуле. Clear на сыпящемся диске без замены — косметика.

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

До физической замены сфотографируйте/запишите: zpool status -P, серийник SMART, номер корзины BMC, by-id. Путаница «диск 3 vs слот 3» — типичная причина replace здорового leaf.

zpool status -P rpool
zpool labelclear -n /dev/disk/by-id/ata-NEW_SERIAL
smartctl -H /dev/disk/by-id/ata-NEW_SERIAL

labelclear -n (dry-run) на новом диске показывает, нет ли на нём чужих меток ZFS. На диске из другого сервера без export метки могут быть. labelclear без -n на диске, который всё ещё member rpool — катастрофа; только новый/пустой носитель.

Во время resilver смотрите scan: в zpool status: скорость и ETA. Падение скорости до нуля и рост ошибок на втором диске — стоп нагрузку, проверьте кабель/PSU/backplane. Не добавляйте второй replace «параллельно» в тот же vdev без понимания топологии.

Для NVMe имена nvme0n1 ещё охотнее ездят после ребута, чем sd. Только by-id/by-path в командах и в документации стойки.

Как проверить, что проблема устранена

zpool status rpool
zpool list rpool
smartctl -H /dev/disk/by-id/ata-NEW_SERIAL
pvesm status
qm status 101

STATE ONLINE, scan не resilver (или resilver 100% без новых errors). Ошибки read/write/cksum на новом диске не растут. VM на датасетах пула работают. После суток — повторный zpool status, не только сразу после replace.

Resilver на rpool с корневым датасетом грузит и ОС pve1. Отложите vzdump и live-migration на этот узел до scan: none в zpool status. Иначе получите и degraded, и сорванный backup.

Если не помогло

• Resilver вечный / рестарт с нуля: второй диск сыпется, канал, RAM. Остановите лишнюю нагрузку, проверьте память.
• После replace пул не импортируется — импорт, не второй replace.
• GUI всё ещё degraded: другой пул, не rpool.
• ASHIFT нового диска: для замены leaf обычно наследует vdev; не собирайте новый пул поверх.
• Корневой rpool: держите консоль BMC на время resilver.

Профилактика

• Только by-id в командах и документации слотов.
• SMART + zpool status в мониторинге.
• Hot spare, если политика позволяет.
• Scrub по расписанию, не в пик backup.
• Перед массовой нагрузкой — health-check.

FAQ

Можно ли replace меньшим диском?

Нет, если он меньше заменяемого. Больше — обычно да, полезный размер vdev не вырастет, пока не заменены все leaf по правилам версии/фичи.

Нужно ли zpool offline перед replace?

Если диск ещё частично отвечает и мешает — offline по id, затем replace. Уже UNAVAIL — часто сразу replace.

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

Scrub проверяет все данные. Resilver достраивает заменённый диск. На degraded не включайте scrub «для скорости».

zpool attach вместо replace?

Attach добавляет устройство в mirror. Для замены умершего leaf — replace, не третий диск вслепую.

Можно ли на время resilver гонять VM?

Технически да, нагрузка удлиняет resilver и бьёт по оставшимся дискам. Для корневого rpool лучше снизить IO, критичные VM — мигрировать, если есть второй узел.