Proxmox ZFS — DEGRADED: заміна диска без побічних наслідків

Що насправді означає “DEGRADED” в Proxmox + ZFS

У ZFS DEGRADED означає, що пул ще доступний, але принаймні один vdev (віртуальний пристрій) втратив надлишковість
або має компонент, який недоступний або некоректно працює. Важлива не сама назва, а її наслідки:

• Ви на один збій від втрати даних, якщо це mirror з однією втраченю стороною або RAIDZ без резерву парності.
• Продуктивність часто падає, бо ZFS може реконструювати читання, повторювати I/O або обходити нестабільний пристрій.
• Scrub та resilver стають ризиковими операціями: вони навантажують залишкові диски, а саме цього ви не хочете під час старіння обладнання.

Proxmox тут переважно посередник. Він використовує ZFS як бекенд сховища (часто для rpool і іноді для пулів VM)
і показує zpool status в інтерфейсі. Справжній контроль — у shell.

«Замінити диск» звучить як апаратна операція. У ZFS це операція міграції даних із залежністю від апаратної частини. Ставтеся до неї відповідно.

Швидкий план діагностики (перевірити першим/другим/третім)

Коли пул переходить у degraded, ваша задача — швидко відповісти на три питання: який диск? чи він справді виходить з ладу чи просто зник?
чи пул достатньо стабільний, щоб безпечно запускати resilver?

Перше: підтвердьте стан пулу і точного члена vdev, який проблемний

Не вгадуйте за GUI Proxmox. Отримайте авторитетний статус від ZFS.

Друге: визначте, чи це «мертвий диск», чи «проблема шляху»

Диск може виглядати як збій через скидання контролера, поганий SATA-кабель, проблемний слот бекплейну або перенумерацію пристроїв.
Виправлення різниться — і сліпа заміна обладнання може погіршити ситуацію.

Третє: оцініть ризики перед тим, як навантажувати пул

Якщо на залишкових дисках є випадки перерозподілених секторів, помилки читання або тайм-аути, варто сповільнити I/O,
запланувати вікно або зробити знімок/реплікацію перед resilver.

Найшвидший шлях знайти вузьке місце: ZFS status → kernel logs → SMART. Якщо ці три джерела узгоджуються — дійте.
Якщо ні — зупиніться і з’ясуйте причину.

Цікаві факти та історичний контекст (чому ZFS поводиться так)

• ZFS походить від Sun Microsystems середини 2000-х з end-to-end checksumming як базовою функцією, а не доповненням.
• “Copy-on-write” пояснює, чому ZFS не любить напівправду: він записує нові блоки, а потім оновлює вказівники, що полегшує виявлення тихої корупції.
• ZFS не «перебудовує», він «resilver» — тобто відновлює лише ті блоки, які фактично використовуються, а не весь необроблений пристрій.
• RAIDZ розроблявся, щоб вирішити проблему write hole у RAID-5/6 шляхом інтеграції управління парністю з моделлю транзакцій файлової системи.
• Імена пристроїв на кшталт /dev/sda нестабільні; стійка ідентифікація через /dev/disk/by-id стала найкращою практикою через зміну нумерації в Linux.
• Scrub потрібен, бо контрольні суми треба «прогнати»: ZFS виявляє корупцію, але scrub змушує читати й перевіряти дані проактивно.
• Поява Advanced Format (4K сектора) принесла чимало проблем; ashift — спосіб ZFS вирівнювати алокації під фізичний розмір сектора.
• SMART — це не вирок, а погодинний звіт: багато дисків “помирають” з виглядом «здоровий», а інші довго працюють у стані “failing”.

Одна цитата, перефразована від Gene Kranz (керівник польотів NASA), звучить доречно: перефразовано: будьте жорсткими та компетентними.
У термінах зберігання: не імпровізуйте і не чіпайте дві речі одночасно.

Перед тим як торкатися обладнання: запобіжні заходи проти побічних наслідків

Використовуйте стабільні ідентифікатори дисків (серійний номер), а не те, що Linux назвав сьогодні

Якщо ви працюєте з дисками за /dev/sdX тільки, ви граєте в рулетку з підмазаним колесом. Оновлення Proxmox,
оновлення ядра, скидання контролера або просто перезавантаження можуть перемішати нумерацію. ZFS також може зберігати шляхи в різних формах.
Закріпіть рішення за незмінними фактами: WWN, серійний номер і місце в шасі.

Визначте межі впливу

Якщо пул хостить диски VM (zvol), resilver — це інтенсивне I/O. Якщо можна евакуювати критичні VM — зробіть це.
Якщо ні, все одно дійте навмисно: обмежте навантаження, уникайте паралельних робіт і пильно стежте за затримками.

Не «виправляйте» дві проблеми одночасно

Заміна диска — уже контрольована аварійна операція. Не поєднуйте її з оновленням ядра, прошивкою HBA,
змінами флагів ZFS або «швидким прибиранням кабелів». Ви хочете причинність і можливість відкотитися.

Жарт #1: Масиви зберігання не мають настрою. Вони мають наслідки, і вони завжди пам’ятають, що ви зробили.

Практичні завдання з командами, виводами та рішеннями (12+)

Все нижче написано для типового вузла Proxmox з ZFS на Linux. Команди виконуються з правами root або з sudo.
Замініть імена пулів/пристроїв на власні. Якщо ваш пул — rpool, добре. Якщо tank, використайте його.

Завдання 1: Підтвердьте здоров’я пулу і визначте проблемний член

cr0x@server:~$ sudo zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 00:14:12 with 0 errors on Thu Dec 19 02:10:03 2025
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321   FAULTED     12     0     0  too many errors

errors: No known data errors

Що це означає: У вас mirror з однією стороной у стані faulted. Читання обслуговуються з залишкового диска.
Пул ще працює, але надлишковість для того vdev втрачена.
Рішення: Замінити ...654321. Не від’єднуйте здоровий диск. Не «clear» помилок і не надійтеся.

Завдання 2: Зіставте ID ZFS з фізичними дисками (WWN/серійник)

cr0x@server:~$ ls -l /dev/disk/by-id | egrep 'S2Y3NX0K123456|S2Y3NX0K654321'
lrwxrwxrwx 1 root root  9 Dec 26 09:10 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 09:10 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321 -> ../../sdb

Що це означає: Наразі здоровий диск — /dev/sda, а поганий — /dev/sdb.
Ця відповідність може змінитися після перезавантаження.
Рішення: Працюйте через /dev/disk/by-id/ata-..., а /dev/sdb використовуйте лише для моментальних SMART-перевірок.

Завдання 3: Перевірте журнали ядра на тайм-аути/скидання (щоб відрізнити диск від шляху)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'sdb|ata|I/O error|timeout|reset' | tail -n 25
Dec 26 08:41:12 server kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 26 08:41:12 server kernel: ata2.00: failed command: READ DMA EXT
Dec 26 08:41:12 server kernel: blk_update_request: I/O error, dev sdb, sector 118782976 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 26 08:41:13 server kernel: ata2: hard resetting link
Dec 26 08:41:18 server kernel: ata2: link is slow to respond, please be patient (ready=0)
Dec 26 08:41:23 server kernel: ata2.00: configured for UDMA/133

Що це означає: Схоже на реальні I/O-помилки та скидання лінку. Може бути диск або кабель/бекплейн.
Рішення: Якщо це hot-swap лоток, обережно перепідключіть диск один раз перед заміною. Якщо проблема повторюється — замініть диск і розгляньте заміну слота/кабелю пізніше.

Завдання 4: Отримайте швидкий SMART-підсумок стану

cr0x@server:~$ sudo smartctl -H /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-5-pve] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

Що це означає: Диск визнає, що він помер.
Рішення: Замінити диск. Достатньо діагностики.

Завдання 5: Витягніть SMART-атрибути, що мають значення (тайм-аути vs знос vs медіа)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'Serial Number|Reallocated|Pending|Offline_Uncorrectable|CRC|Power_On_Hours|Media_Wearout|Percentage_Used' 
Serial Number:                       S2Y3NX0K654321
Power_On_Hours:                      43120
Reallocated_Sector_Ct:               48
Current_Pending_Sector:              9
Offline_Uncorrectable:               9
UDMA_CRC_Error_Count:                0

Що це означає: Pending та uncorrectable сектора — класична медіа-помилка. CRC = 0, отже менше шансів на проблему з кабелем.
Рішення: Замінити диск. Якби було багато CRC-помилок — підозрюйте кабелі/бекплейн і зверніть на це більше уваги.

Завдання 6: Перевірте топологію пулу (mirror vs RAIDZ) перед командами заміни

cr0x@server:~$ sudo zpool get -H -o value ashift rpool
12

Що це означає: ashift=12 (4K сектора). Це бажано в сучасних системах.
Рішення: Переконайтеся, що диск-замінник не менший і підходить для вирівнювання 4K. Змінити ashift на існуючому члені vdev на місці неможливо.

Завдання 7: Перевірте, що диск-замінник видно і не зайнятий

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINT
NAME    SIZE MODEL             SERIAL           TYPE MOUNTPOINT
sda   476.9G SAMSUNG MZ7LN512  S2Y3NX0K123456   disk 
├─sda1 1007K                    0               part 
├─sda2    1G                    0               part 
└─sda3 475.9G                    0               part 
sdb   476.9G SAMSUNG MZ7LN512  S2Y3NX0K654321   disk 
├─sdb1 1007K                    0               part 
├─sdb2    1G                    0               part 
└─sdb3 475.9G                    0               part 
sdc   476.9G SAMSUNG MZ7LN512  S2Y3NX0K777777   disk 

Що це означає: Новий диск — sdc і виглядає порожнім (без розділів). Добре.
Рішення: Також використайте /dev/disk/by-id для sdc. Підтвердіть, що серійник відповідає наклейці на коробці/лотку.

Завдання 8: Підтвердіть постійний ідентифікатор для нового диска

cr0x@server:~$ ls -l /dev/disk/by-id | grep S2Y3NX0K777777
lrwxrwxrwx 1 root root  9 Dec 26 09:16 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777 -> ../../sdc

Що це означає: У вас є стабільний ідентифікатор для диска-замінника.
Рішення: Продовжуйте з zpool replace використовуючи шляхи by-id.

Завдання 9: Правильно замініть член (дозвольте ZFS зробити свою роботу)

cr0x@server:~$ sudo zpool replace rpool \
  /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321 \
  /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777

Що це означає: ZFS приєднає новий диск і почне resilver на нього.
Рішення: Не перезавантажуйте систему. Не видаляйте залишковий здоровий диск. Моніторьте прогрес resilver.

Завдання 10: Слідкуйте за прогресом resilver і перевірте, що він рухається

cr0x@server:~$ watch -n 5 sudo zpool status rpool
  pool: rpool
 state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Fri Dec 26 09:18:41 2025
        112G scanned at 1.21G/s, 38.2G issued at 423M/s, 475G total
        38.2G resilvered, 8.04% done, 00:17:42 to go
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777   ONLINE       0     0     0  (resilvering)

Що це означає: Resilver активний, показує пропускну здатність, ETA та скановані/видані дані. Це хороший знак.
Рішення: Якщо «issued» тримається на 0 хвилинами, а «scanned» повільно зростає — можлива вузька пляма або помилки. Перевірте журнали та SMART на вижившому диску.

Завдання 11: Перевірте вплив на навантаження/затримку вузла (щоб уникнути випадкового простою)

cr0x@server:~$ sudo iostat -x 2 5
Linux 6.8.12-5-pve (server) 	12/26/2025 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.12    0.00    3.44   24.66    0.00   63.78

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
sda              98.0   91200.0     0.0   0.00    3.10   930.6     21.0    980.0    8.60    46.7     0.41  38.0
sdc              44.0   40120.0     0.0   0.00    4.90   912.7     62.0   15200.0    2.40   245.2     0.44  29.5

Що це означає: %iowait підвищений. Це нормально під час resilver. %util не перевантажено — є запас.
Рішення: Якщо iowait руйнує затримки VM, обмежте навантаження або заплануйте тихий вікно. Уникайте запуску бекапів або великих міграцій під час resilver.

Завдання 12: Підтвердіть, що пул повернувся в ONLINE і старий пристрій зник

cr0x@server:~$ sudo zpool status -v rpool
  pool: rpool
 state: ONLINE
  scan: resilvered 475G in 00:22:19 with 0 errors on Fri Dec 26 09:41:00 2025
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        ONLINE       0     0     0
          mirror-0                                   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777   ONLINE       0     0     0

errors: No known data errors

Що це означає: Ви повернулися до надлишковості. Немає помилок. Це бажаний стан.
Рішення: Тепер зробіть прибирання та верифікацію: план scrub, налаштування оповіщень, маркування й нотатки післяінцидентного розгляду.

Завдання 13: Якщо диск показаний як “UNAVAIL”, а не “FAULTED”, перевірте, чи він просто відсутній

cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: DEGRADED
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321   UNAVAIL      0     0     0  cannot open

Що це означає: ZFS не може відкрити пристрій; це може бути мертвий диск або проблема шляху.
Рішення: Перевірте, чи існує шлях у /dev/disk/by-id. Якщо він зник, шукайте проблеми з контролером/бекплейном перед тим, як оголосити диск «збитим».

Завдання 14: Перевірте, чи існує відсутній шлях пристрою (чи ні)

cr0x@server:~$ test -e /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321; echo $?
1

Що це означає: Код виходу 1 означає, що шлях не існує. ОС його не бачить.
Рішення: Перевірте фізичне сидіння, слот бекплейна, журнали HBA. Якщо він повернеться — можливо замість replace варто зробити zpool online.

Завдання 15: Якщо диск повернувся, спробуйте його online (тільки якщо йому довіряєте)

cr0x@server:~$ sudo zpool online rpool /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321

Що це означає: ZFS спробує повернути пристрій. Якщо це було транзитне явище, пул може повернутися в ONLINE без заміни.
Рішення: Якщо SMART все ще виглядає погано або журнали показують повторні скидання, не шкодуйте — замініть його.

Завдання 16: Очищайте старі лічильники помилок тільки після усунення кореневої проблеми

cr0x@server:~$ sudo zpool clear rpool

Що це означає: Це очищує лічильники помилок і деякі стани fault.
Рішення: Використовуйте це, щоб підтвердити, що виправлення утрималося (помилки залишаються на 0). Не використовуйте як спосіб «загримувати» пул без реальної заміни.

Жарт #2: Якщо ви «clear» помилки пулу, не виправивши нічого, вітаю — ви успішно заглушили протипожежний сигнал, поки хліб все ще горить.

Сценарії заміни: mirror vs RAIDZ, hot-swap vs cold-swap

Mirror vdev: простий випадок (але його легко зіпсувати)

Mirrors дружні до операцій. Замінюєте один диск, resilver, і готово. Режим відмови — людський:
хтось витягує не той диск, замінює на диск трохи менший, використовує нестабільні імена пристроїв або від’єднує невірного члена.

Рекомендований підхід:

• Ідентифікуйте збійний диск за серійним номером і лотом, а не за sdb.
• Використовуйте zpool replace зі шляхами /dev/disk/by-id.
• Моніторте resilver і системний I/O. Resilver — це не тихий фон; це вантажівка.
• Переконайтесь, що zpool status повернувся в ONLINE, потім за можливості запустіть scrub у вікні технічного обслуговування.

RAIDZ vdev: заміна теж проста; наслідки — інші

У RAIDZ пул може залишатися онлайн з відсутніми дисками в залежності від рівня парності (RAIDZ1/2/3).
Але під час деградації кожне читання даних, що стосуються відсутнього диску, може вимагати реконструкції, що навантажує інші диски.
Потім resilver додає ще більше I/O. Ось як «один збій диска» стає «чому три диски тайм-аутять».

Метод той самий: zpool replace члена. Операційна позиція змінюється:

• Не запускайте scrub і resilver одночасно, якщо ви не полюбляєте довгі нічні ремонти.
• Розгляньте зниження навантаження під час resilver.
• Якщо інший диск показує помилки — пауза і рішення: бекап/реплікація перед продовженням.

Hot-swap лотки: довіряйте, але перевіряйте

Hot-swap — це не «підключив і молився». Це «hot-swap, якщо бекплейн, HBA і ОС погоджуються».
На Proxmox зазвичай можна замінити диск на ходу, але ви повинні:

• Підтвердити правильний індикатор лотка (якщо є) або використати процес зіставлення (серійник ↔ лоток).
• Вставити новий диск і впевнитися, що він з’явився в /dev/disk/by-id.
• Потім виконати zpool replace. Не раніше.

Cold swap (вимикання): інколи нудно — правильно

Якщо апаратна частина сумнівна (побутові SATA-контролери, проблемні бекплейни, старий BIOS або історія скидань лінку),
холодна заміна може знизити ризики. Це також чистіше операційно, якщо пул уже нестабільний.
Після завантаження ви все одно виконуєте ті ж перевірки, бо нумерація може змінитися.

Контрольні списки / покроковий план (production-ready)

Контрольний список A: план реагування на “Я побачив DEGRADED”

1. Зафіксуйте поточний стан: zpool status -v і збережіть в тикеті/нотатках.
2. Перевірте, чи зростають лічильники помилок: повторіть zpool status через 2–5 хвилин. Чи збільшуються READ/WRITE/CKSUM?
3. Перегляньте журнали ядра на предмет скидань/тайм-аутів: journalctl -k -b.
4. SMART-перевірка підозрілого диска і виживших членів того ж vdev.
5. Вирішіть, чи можна діяти вживу або потрібне вікно обслуговування.

Контрольний список B: безпечні кроки заміни (член mirror або RAIDZ)

1. Ідентифікуйте збійного члена за zpool status (віддавайте перевагу by-id).
2. Зіставте його з серійником і міткою лотка через ls -l /dev/disk/by-id та інвентар шасі.
3. Вставте диск-замінник. Підтвердіть появу в /dev/disk/by-id.
4. Переконайтеся, що розмір диска-замінника не менший за старий: lsblk.
5. Запустіть zpool replace <pool> <old> <new>.
6. Моніторте resilver: zpool status до завершення. Стежте за системною затримкою.
7. Коли в ONLINE — зафіксуйте тривалість resilver і будь-які помилки.
8. За потреби заплануйте scrub у наступне тихе вікно (не одразу, якщо система під навантаженням).

Контрольний список C: валідація після заміни

1. zpool status -v показує ONLINE і 0 відомих помилок даних.
2. SMART нового диска має чисту базу (збережіть звіт SMART).
3. Переконайтеся, що алерти в Proxmox і в системі моніторингу очищені.
4. Оновіть інвентарь: відповідність лоток → серійник, гарантійний трекінг і дата заміни.

Контрольний список D: якщо resilver повільний або завис

1. Перевірте, чи інший диск не почав також видавати помилки (SMART + журнали ядра).
2. Перевірте на насичення: iostat -x і навантаження VM.
3. Розгляньте паузу некритичних завдань (бекапи, реплікація, великі переміщення даних).
4. Якщо помилки зростають — припиніть зміни і плануйте контрольований простій з готовими бекапами.

Типові помилки: симптом → корінь проблеми → виправлення

1) Пул досі DEGRADED після заміни

Симптом: Ви замінили диск, але zpool status все ще показує DEGRADED і старе ім’я пристрою лишається.

Корінь проблеми: Ви використали невірний ідентифікатор (наприклад, замінили /dev/sdb, а ZFS відслідковував by-id), або приєднали диск не як replace.

Виправлення: Використайте zpool status щоб знайти точний рядок пристрою, потім виконайте zpool replace pool <that-exact-old> <new-by-id>. Уникайте /dev/sdX.

2) Диск-замінник «занадто малий», хоча той самий модель

Симптом: zpool replace повідомляє «device is too small».

Корінь проблеми: Виробники можуть мати різну корисну ємність між прошивками, або старий диск мав трохи більший звітований розмір.

Виправлення: Використовуйте диск однакового або більшого розміру. Для mirror-ів завантажувального пулу краще купити наступний обсяг, ніж грати в «номер моделі».

3) Resilver повзе, вузол непридатний

Симптом: Затримки VM, високий I/O wait, користувачі скаржаться, ETA resilver росте.

Корінь проблеми: Конфлікт навантаження (записи VM + читання/записи resilver), а також можливий проблемний залишковий диск.

Виправлення: Зменшіть навантаження (пауза важких задач, міграція непотрібних VM), перевірте SMART виживших дисків і заплануйте вікно обслуговування. Якщо виживший диск помиляється — це фактична аварія «другий диск помирає».

4) Ви витягли невірний диск і тепер пул OFFLINE

Симптом: Пул впав, VM призупинилися/падали, і zpool status показує відсутні пристрої.

Корінь проблеми: Людська помилка в ідентифікації: невірне мапування лотків, нестабільність імен або відсутність процедури індикації LED.

Виправлення: Вставте правильний диск негайно. Якщо ви витягли здоровий член mirror — поверніть його першочергово. Потім переоцініть. Ось чому мітки лотків і запис серійників важливі.

5) Заміна диска на boot pool, але вузол не завантажується

Симптом: Після заміни диска в rpool система не завантажується, якщо старий диск видалити.

Корінь проблеми: Завантажувач/EFI запис не був інстальований або віддзеркалений на новий пристрій. ZFS не завжди автоматично віддзеркалює стан bootloader-а.

Виправлення: Забезпечте інсталяцію Proxmox boot tooling/EFI на всі завантажувальні диски. Перевіряйте тимчасовим перемиканням порядку завантаження або контрольним тестом завантаження.

6) CKSUM помилки при «здоровому» SMART

Симптом: zpool status показує checksum-помилки на пристрої, але SMART виглядає в нормі.

Корінь проблеми: Часто проблеми з кабелями, бекплейном, HBA або живленням, що викликають корупцію даних в транзиті.

Виправлення: Пересадіть/замініть кабелі, перемістіть диск в інший слот/порт контролера, перевірте стабільність прошивки HBA. Очистіть помилки після виправлення і спостерігайте, чи повертаються вони.

Три корпоративні міні-історії з реального життя

Міні-історія 1: Інцидент через хибне припущення

Середня компанія тримала Proxmox на двох вузлах, кожен з mirror boot pool та окремим RAIDZ для VM.
Одного ранку вузол показав DEGRADED. Інженер on-call побачив /dev/sdb у швидкому погляді на zpool status,
припустив, що це «Bay 2», і попросив персонал витягти той диск.

Персонал зробив саме так, але лотки не були підписані, а шасі недавно перешнуроване.
Витягнули здоровий член mirror, а не пошкоджений. Пул не впав відразу, бо ZFS толерантний — до певного моменту.
Виживші диски зазнали додаткового навантаження, і один із них почав також помилятися.

Відновлення було болючим, але повчальним: вставили назад витягнутий диск, дочекалися стабілізації і згодом повторно ідентифікували через
/dev/disk/by-id, перевірили серійники і створили наклейки на лотках під час інциденту.

Неправильне припущення було не «люди помиляються». Воно було «імена пристроїв стабільні». Вони — ні. Навіть в гарний день.

Міні-історія 2: Оптимізація, що відвернулась

Інша організація хотіла швидші resilver і scrub. Хтось вирішив, що «більше паралелізму краще» і агресивно налаштував ZFS:
вищі швидкості сканування, більше одночасних операцій — весь набір «підніміть графік».
В лабораторії це виглядало добре. У production це зіткнулося з реальними навантаженнями: бази даних, бекапи і трафік реплікації.

Під час події resilver почався з вражаючою пропускною здатністю, потім вузол став тайм-аутити I/O гостей.
Кластер VM не впав, але став тягнутися як патока. Оператори спробували перезапустити сервіси і мігрувати VM,
що додало ще більше I/O. Resilver загальмував ще більше. Більше повторів. Більше проблем.

Вони стабілізувалися, відкотивши «оптимізацію» до консервативних налаштувань і дозволивши resilver працювати в стійкому темпі,
віддавши пріоритет затримці сервісів над показниками. Після інциденту вони зберегли консервативні значення та створили рукопис:
під час resilver призупиняти непотрібні роботи і вважати затримку сховища основним SLO.

Урок: швидкість resilver — не ваятельний показник. Єдине, що важить — «закінчити без другого збою, поки користувачі працюють».

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Регульований бізнес тримав Proxmox з mirror-ами і сувору звичку: кожен лоток диска мав мітку,
кожна мітка відповідала записаному серійному номеру, і кожна заміна виконувалася через by-id з
скриншотами zpool status, прикладеними до тикету.

Коли пул деградував під час святкового тижня, на чергуванні був загальний інженер, не спеціаліст зі зберігання.
Він дотримався рукопису: перевірив статус ZFS, зіставив серійник, верифікував SMART, підтвердив серійник замінника
і лише тоді замінив. Без хитрощів. Без скорочень.

Resilver закінчився чисто. Scrub пізніше не показав помилок. Пост-інцидентний огляд був коротким, бо майже нічого не було, що слід переглядати.
Їхня «нудна практика» запобігла найпоширенішій катастрофі: витягнути не той диск або замінити неправильного члена vdev.

Нудне недооцінене. Нудне — те, як ви спите.

FAQ

1) Чи користуватись GUI Proxmox для заміни диска, чи CLI?

Використовуйте CLI для фактичних операцій ZFS. GUI підходить для видимості, але zpool status — джерело істини,
і вам потрібні команди та виводи, які можна скопіювати в нотатки інциденту.

2) Чи можна перезавантажити під час resilver?

Уникайте. ZFS зазвичай може продовжити resilver після перезавантаження, але reboot додає ризики: перенумерація пристроїв,
особливості HBA і шанс, що маргінальний диск не повернеться. Якщо потрібно перезавантажити для стабільності — робіть це свідомо і документуйте стан до і після.

3) У чому різниця між zpool replace і zpool attach?

replace замінює один пристрій на інший і запускає resilver. attach додає новий пристрій до mirror (перетворює однодисковий vdev у mirror або розширює mirror).
Для збійного члена mirror майже завжди потрібен replace.

4) Чи запускати scrub одразу після заміни?

Не одразу, якщо ви не в тихому вікні і не готові витримати навантаження. Resilver вже читає багато даних.
Заплануйте scrub після охолодження системи, особливо для RAIDZ.

5) Диск показує UNAVAIL. Чи він мертвий?

Не обов’язково. UNAVAIL може означати, що ОС його не бачить (шлях/кабель/контролер) або диск помер.
Перевірте /dev/disk/by-id, журнали ядра та SMART, якщо пристрій з’явився знову.

6) Чи можна замінити диск на більший і отримати більше місця?

Можна замінити на більший, але корисний простір з’явиться лише після того, як усі члени vdev будуть оновлені і ZFS дозволить розширення.
Mirrors розширюються після того, як обидва боки більші; RAIDZ — після оновлення всіх дисків у цьому vdev.

7) Чому ZFS показує помилки, а додатки виглядали нормально?

Бо ZFS може прозоро виправляти багато помилок завдяки надлишковості та контрольним сумам. Це не «все гаразд», це «виявлено і виправлено».
Ставтеся до виправлених помилок як до попередження: щось деградує.

8) Що робити, якщо виживший диск mirror починає показувати SMART-помилки під час resilver?

Це неприємний момент: ви можете бути на порозі подвійного збою. Якщо можливо, зменшіть навантаження, пріоритезуйте бекап/реплікацію критичних даних
і розгляньте варіант зупинки та контролю відновлення. Продовжувати можна, але ви ризикуєте останньою доброю копією в цьому vdev.

9) Чи автоматично ZFS віддзеркалює завантажувач Proxmox на rpool?

Не завжди надійно. ZFS зеркалить блоки даних; здатність до завантаження залежить від інсталяції EFI/завантажувача та записів прошивки.
Після заміни boot-дисків перевіряйте, щоб кожен диск був завантажувальним, якщо ваша архітектура цього вимагає.

10) Чи безпечно «offline» диск перед його витягуванням?

Так, коли ви свідомо видаляєте члена (особливо у hot-swap). Offlining зменшує несподіванки, повідомивши ZFS, що пристрій іде.
Але ніколи не offline останнього доброго члена vdev. Спочатку підтвердьте топологію.

Висновок: наступні кроки після повернення в ONLINE

Повернення від DEGRADED до ONLINE — тактична перемога. Стратегічна перемога — забезпечити, щоб наступний збій диска
пройшов нудно, швидко і без геройських зусиль.

1. Задокументуйте інцидент: вставте zpool status -v до/після, вивід SMART і який серійник було замінено.
2. Виправте борг ідентифікації: промаркуйте лотки, ведіть мапу серійник→слот і стандартизуйте використання /dev/disk/by-id.
3. Перевірте моніторинг: алерти для стану ZFS-пулів, критичних SMART-атрибутів і скидань лінку ядра.
4. Заплануйте scrubs свідомо: регулярно, щоб виявляти «рот», але не настільки агресивно, щоб постійно навантажувати диски.
5. Практикуйте runbook: найкращий час вчитися zpool replace — не під час першого переходу пулу в degraded.

ZFS дає вам шанс поборотися. Не витрачайте його на здогадки. Замініть правильний диск, у правильний спосіб, і тримайте побічні наслідки там, де їм місце: ніде.