Найнебезпечніший момент при відновленні ZFS — перші п’ять хвилин. Не тому, що ZFS крихкий, — а тому, що люди такі. Ви на виклику, пул “UNAVAIL,” панелі моніторингу червоні, і хтось пропонує «просто перезавантажити». Ось так ви перетворюєте керований інцидент на криміналістику для хобі.
Це польовий посібник для відновлення пулу ZFS з мінімальною драмою: що перевіряти насамперед, які команди запускати, як читати вивід і які рішення приймати на основі цього виводу. Це думка практичного інженера. Припускає виробничий тиск. І припускає, що ви хочете зберегти і роботу, і дані.
Мислення при відновленні: перестаньте копати
Відновлення пулу ZFS — це радше робота з доказами на місці ДТП, ніж «ремонт файлової системи». Інструменти потужні, структури даних стійкі, і ви цілком можете погіршити ситуацію, якщо будете креативні під стресом.
Три правила, що вберігають від проблем:
- Мінімізуйте запис до того, як зрозумієте помилку. Записи можуть перезаписати ту саму метадані, які потрібні для чистого відновлення.
- Надавайте перевагу спостереженню над дією. Перші команди мають бути лише для читання: статус, виявлення імпорту, журнали ядра.
- Змінюйте одну змінну за раз. Якщо ви одночасно міняєте диски, кабелі й шляхи пристроїв, ваш хронологічний звіт стане вигадкою.
Також: не «прибирайте» мітки й розділи, поки не збережете достатньо стану, щоб відкотити свої рішення. ZFS прощає помилки; він не читає думки.
Жарт №1: «Я просто запущу zpool import -f і подивлюсь, що станеться» — це схоже на «я трохи покерую штурвалом літака і гляну, що станеться» для сховищ.
Швидка діагностика (перший/другий/третій)
Це найкоротший шлях до відповіді «що насправді зламалося?». Він призначений для швидкого виявлення вузького місця: апаратне забезпечення, топологія, метадані чи людська помилка.
Перший: проблема видимості пристрою чи проблема метаданих ZFS?
- Перевірте журнали ядра на предмет скидань дисків/лінків (SATA, SAS, NVMe тайм-аути).
- Перевірте, чи ОС все ще бачить пристрої (шляхи by-id, multipath, відображення шасі).
- Запустіть виявлення імпорту без власне імпорту, щоб перевірити, чи ZFS може читати мітки.
Якщо пристрої відсутні на рівні ОС, ZFS поки не допоможе. Виправте кабелі, HBA, проблеми з експандером, зонуванням, multipath — і лише потім повертайтеся до ZFS.
Другий: який стан пулу і який у вас тип надмірності?
- Mirror і RAIDZ по-різному змінюють ризик. Деградований mirror зазвичай рутинна справа. Деградований RAIDZ з кількома проблемами — складніший танець.
- Шукайте «занадто багато помилок» проти «пристрій видалено». Це різні моди відмови з різними діями.
Третій: мова про корупцію чи просто «не збирається пул»?
- Ознаки корупції: помилки контрольних сум, «permanent errors», помилки читання конкретних файлів, повторні перезапуски resilver.
- Ознаки зборки: пул не імпортується, відсутні топ-рівневі vdev, застарілий cachefile, перейменовані пристрої, змінений порядок HBA.
Коли ви можете класифікувати інцидент як «видимість», «збірка», «деградований, але імпортований» або «корупція», ви припиняєте метушню й починаєте діяти.
Цікаві факти та історичний контекст (коротко)
- ZFS з’явився в Sun Microsystems у середині 2000-х з метою забезпечення цілісності даних від початку до кінця, а не лише зручності.
- Модель «copy-on-write» означає, що ZFS зазвичай не перезаписує живі метадані на місці, тому багато режимів відмови відновлювані, якщо уникати додаткових записів.
- RAIDZ — відповідь ZFS на класичну проблему «RAID5 write hole», опираючись на транзакційні семантики замість батарейних кешів контролера.
- ZFS контролює контрольні суми даних і метаданих (для метаданих це обов’язково), тому «checksum error» часто вказує на реальну корупцію, не просто косметичне попередження.
- OpenZFS став крос‑платформовим проектом; поведінка трохи відрізняється між платформами й версіями.
- Властивість
ashiftіснує через відмінності фізичних розмірів секторів і «брехню» дисків; невірне вирівнювання може тихо зіпсувати продуктивність і навіть вплинути на передбачуваність відновлення. - Мітки пулу ZFS зберігаються в кількох місцях на кожному vdev, тому «пошкодження мітки» часто відновлюване, якщо хтось не перезаписує невірні дані.
- Scrub не завжди був стандартною процедурою. Багато організацій почали робити scrubs рутинно лише після того, як великі ємності дисків зробили латентні секторні помилки поширеними.
- Спеціальні vdev та L2ARC прискорили пул, але також додали нові способи нашкодити собі, якщо трактувати «cache device» як змінний елемент без розуміння його ролі.
Тріаж: підтвердити, ізолювати, зберегти
Якщо ваш пул щойно пішов боком, не починайте з «ремонту». Почніть з підтвердження (що правда), потім ізоляції (зупиніть витік), і лише потім збереження (зафіксуйте стан для подальшого аналізу).
Підтвердити: що саме змінилося?
Більшість ZFS-аутеджів не містять містичних корупцій. Вони буденні: диск відвалився, HBA скинувся, кабель зачепили під час «обслуговування», alias multipath змінився, оновлення прошивки змінило порядок. Пул зазвичай у порядку; ваші припущення — ні.
Ізолювати: зменшіть шум і побічні ефекти
- Якщо додатки б’ють по деградованому пулу, призупиніть або обмежте їх. Resilver під навантаженням можливий, але повільніший і ризикованіший.
- Якщо пул «флапає» (пристрої вмикаються/вимикаються), зупиніть метушню: спочатку виправте рівень лінку.
- Якщо вас тягне виконати «cleanup» команди, зупиніться і зробіть знімки/експорт лише коли це безпечно.
Зберегти: зафіксуйте дані, які знадобляться пізніше
Зберіть стан до будь-яких змін: zpool status, вивід zpool import, lsblk і відображення by-id, журнали ядра. Це допомагає уникнути класики «ми витягли не той диск».
Практичні завдання (команди + значення виводу + рішення)
Це реальні операційні завдання. Кожне містить: команду, приклад виводу, що це означає, і рішення. Підлаштовуйте імена пулів і ідентифікатори пристроїв під ваше середовище.
Завдання 1: Перевірте поточне здоров’я пулу (якщо імпортовано)
cr0x@server:~$ sudo zpool status -xv
all pools are healthyЗначення: ZFS вважає, що все в порядку. Якщо додатки все ще повідомляють про помилки, проблема може бути вище (NFS/SMB, права доступу, баги додатків) або нижче (переривчасті I/O, що ще не проявилися).
Рішення: Якщо пул здоровий, не запускайте команди відновлення «про всяк випадок». Перейдіть до журналів і симптомів додатків.
Завдання 2: Огляньте деградований пул і знайдіть проблемний vdev
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
scan: scrub repaired 0B in 0 days 00:18:22 with 2 errors on Fri Dec 20 02:19:11 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-SAMSUNG_MZ7LM1T9-0 ONLINE 0 0 0
ata-SAMSUNG_MZ7LM1T9-1 ONLINE 0 0 2
ata-SAMSUNG_MZ7LM1T9-2 ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
/tank/projects/db/wal/00000001000000A9000000FFЗначення: Пул імпортований, але є помилки контрольних сум і конкретний файл постраждав. Це не «диск відсутній». Це «ZFS не зміг відновити дані через надмірність» або «надмірність повернула неконсистентні дані».
Рішення: Визначте, чи файл можна відновити (WAL бази даних, похідні артефакти) або треба відновлювати з бекапу. Не тягніть диски лише тому, що у полі CKSUM стоїть «2»; сперечіться з SMART і журналами помилок перш ніж діяти.
Завдання 3: Виявити імпортовані пулі без власне імпорту
cr0x@server:~$ sudo zpool import
pool: tank
id: 10293847566554433211
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
mirror-0 ONLINE
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINEЗначення: ZFS бачить мітки пулу і може зібрати топологію. Добрий знак. Якщо пул тут «не знайдений», швидше за все у вас проблеми з видимістю пристроїв, пошкоджені мітки або ви на неправильному хості.
Рішення: Якщо імпорт можливий, спочатку імпортуйте в режимі лише для читання, коли ситуація неоднозначна.
Завдання 4: Спробуйте обережний імпорт лише для читання
cr0x@server:~$ sudo zpool import -o readonly=on -N tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0Значення: Імпортовано без монтування датасетів (-N) і в режимі лише для читання. Це відмінний стан для огляду: можна перерахувати датасети й властивості без запису нових метаданих.
Рішення: Якщо потрібно скопіювати дані, можна змонтувати окремі датасети в режимі лише для читання. Якщо плануєте ремонт, переходьте в читано-записний режим тільки коли впевнені в стабільності шару пристроїв.
Завдання 5: Перевірте присутність пристроїв на рівні ОС і стабільні ідентифікатори
cr0x@server:~$ ls -l /dev/disk/by-id/ | head
total 0
lrwxrwxrwx 1 root root 9 Dec 26 03:10 ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 -> ../../sdb
lrwxrwxrwx 1 root root 9 Dec 26 03:10 ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 -> ../../sdc
lrwxrwxrwx 1 root root 9 Dec 26 03:10 nvme-SAMSUNG_MZVL21T0HCLR-00B00_S6XYZ123 -> ../../nvme0n1Значення: Посилання by-id існують. Це важливо, бо /dev/sdX порядок — не обіцянка; це пропозиція, що змінюється, коли моргнете.
Рішення: Якщо пул побудовано з шляхами /dev/sdX, заплануйте контрольовану міграцію на by-id у робочий час. Під час відновлення зіставте, який фізичний диск за яким серійним номером, перш ніж щось замінювати.
Завдання 6: Прочитайте думку ядра про ваше сховище (тайм-аути, скидання)
cr0x@server:~$ sudo dmesg -T | egrep -i "zfs|sd[a-z]|ata|nvme|sas|reset|timeout|I/O error" | tail -20
[Thu Dec 26 03:01:22 2025] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 26 03:01:22 2025] ata6.00: failed command: READ FPDMA QUEUED
[Thu Dec 26 03:01:22 2025] blk_update_request: I/O error, dev sdc, sector 1219024896 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 03:01:23 2025] ata6: hard resetting link
[Thu Dec 26 03:01:29 2025] ata6: link is slow to respond, please be patient (ready=0)
[Thu Dec 26 03:01:35 2025] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 03:01:35 2025] sd 6:0:0:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 26 03:01:35 2025] zfs: vdev state changed, pool_guid=10293847566554433211Значення: Класичне «флапання»: скидання лінку, помилки читання і повідомлення ZFS про зміну стану vdev. ZFS може відновитися від транзієнтних помилок, але повторні скидання під час resilver можуть подовжити інцидент.
Рішення: Виправляйте фізичний шар перед діями ZFS, що потребують стійких читань (scrub/resilver). Замініть кабель, змініть порт, перевірте прошивку HBA, перевірте експандер.
Завдання 7: Перевірте SMART/NVMe, щоб підтвердити, що диск справді хворий
cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Model|Serial|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|SMART overall"
Device Model: WDC WD80EFAX-68LHPN0
Serial Number: WD-DEF456
SMART overall-health self-assessment test result: PASSED
5 Reallocated_Sector_Ct 0x0033 095 095 140 Pre-fail Always - 0
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 8
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 8
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 12Значення: «PASSED» — не виправдання. Pending і uncorrectable сектори означають, що диск має нечитаємі області. CRC‑помилки також вказують на проблеми кабелю/бекплейну.
Рішення: Якщо pending/uncorrectable ненульові і ростуть — замініть диск. Якщо CRC‑помилки зростають без інших ознак — спочатку підозрюйте кабелі/бекплейн/HBA.
Завдання 8: Знайдіть, який пристрій відповідає якому відсіку (відображення шасі)
cr0x@server:~$ sudo lsblk -o NAME,SIZE,SERIAL,MODEL,HCTL,WWN
NAME SIZE SERIAL MODEL HCTL WWN
sdb 7.3T WD-ABC123 WDC WD80EFAX-68L 6:0:0:0 0x50014ee2b1234567
sdc 7.3T WD-DEF456 WDC WD80EFAX-68L 6:0:1:0 0x50014ee2b7654321
nvme0n1 1.8T S6XYZ123 SAMSUNG MZVL21T0 - 0x002538b111223344Значення: Ви будуєте відображення від логічних імен пристроїв до фізичних. Це рятує від заміни не того диска — найдорожчий вид кардіо.
Рішення: Перед будь‑якою заміною зафіксуйте серійні номери і місця слотів (інструментами шасі або інвентарем). Якщо не можете змепити — зупиніться і з’ясуйте.
Завдання 9: Очищайте транзієнтні помилки лише після виправлення кореневої причини
cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0Значення: Лічильники скинуто. Це не «лікує» нічого; просто дає чистий стан для моніторингу після виправлення.
Рішення: Використовуйте zpool clear після ремонту кабелів або заміни диска, коли хочете переконатися, що проблема не повертається.
Завдання 10: Замінити несправний диск у mirror (чисто і нудно)
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 FAULTED 0 0 0 too many errorscr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ata-WDC_WD80EFAX-68LHPN0_WD-NEW999
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.
scan: resilver in progress since Thu Dec 26 03:22:01 2025
1.21T scanned at 1.18G/s, 312G issued at 305M/s, 7.30T total
312G resilvered, 4.17% done, 06:35:11 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-NEW999 ONLINE 0 0 0 (resilvering)Значення: Розпочато заміну і триває resilver. Якщо швидкість resilver дуже низька, підозрюйте поточні I/O помилки, SMR-диски під навантаженням або конкурентні робочі навантаження.
Рішення: Моніторте стабільність resilver. Якщо старий диск ще іноді читається, тримайте його підключеним до завершення resilver — якщо він не блокує шинку або не «зависає» контролер.
Завдання 11: Визначити, що не дає імпорту (відсутній пристрій чи інший hostid)
cr0x@server:~$ sudo zpool import tank
cannot import 'tank': pool may be in use from other system, it was last accessed by server-a (hostid=0x12ab34cd) on Thu Dec 26 01:50:20 2025
use '-f' to import anywayЗначення: ZFS вважає, що пул був останнім часом доступний з іншої машини. Це може бути легітимно (спільне сховище, кластер, SAN) або просто застарілий hostid після переміщення дисків.
Рішення: Переконайтесь, що пул не імпортовано десь ще. Якщо впевнені, імпортуйте з примусом, але документуйте й аудитуйте цю операцію.
Завдання 12: Примусовий імпорт безпечно, бажано спочатку в режимі лише для читання
cr0x@server:~$ sudo zpool import -f -o readonly=on -N tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0Значення: Пул імпортовано і стабільний в режимі лише для читання. Це безпечна точка для перевірки даних перед дозволом записів.
Рішення: Якщо інцидент був через несподівані перезавантаження або проблеми HBA, тримайте в режимі лише для читання, поки не переконаєтесь у стабільності пристроїв і не збережете невідтворні дані.
Завдання 13: Імпорт з альтернативним коренем (для середовищ відновлення)
cr0x@server:~$ sudo zpool import -R /mnt -N tank
cr0x@server:~$ sudo zfs mount -a
cr0x@server:~$ mount | grep tank
tank/home on /mnt/home type zfs (rw,xattr,noacl)Значення: -R встановлює альтернативний корінь для монтування. Це корисно в rescue‑shell, на хості для відновлення або коли не хочете колізій із продакшен‑монтуваннями.
Рішення: Використовуйте це при відновленні з живої ОС або при міграції дисків на тимчасовий хост для огляду.
Завдання 14: Перевірте наявність snapshot перед «ремонтом»
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -S creation tank | head
NAME CREATION
tank@autosnap_2025-12-26_0200 Thu Dec 26 02:00 2025
tank@autosnap_2025-12-26_0100 Thu Dec 26 01:00 2025
tank@autosnap_2025-12-26_0000 Thu Dec 26 00:00 2025Значення: Snapshots дають логічну точку відновлення навіть коли апаратний шар хиткий. Вони також дають упевненість для відкату датасетів, якщо потрібно (обережно).
Рішення: Якщо snapshot відсутні й ви розглядаєте деструктивні дії, зупиніться. Варіантів відновлення стало менше.
Завдання 15: Запустіть scrub, коли пул стабільний, і інтерпретуйте результат
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Thu Dec 26 03:40:11 2025
2.88T scanned at 1.02G/s, 1.44T issued at 512M/s, 7.30T total
0B repaired, 19.72% done, 03:05:19 to go
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0Значення: Scrub читає все і перевіряє контрольні суми. «Repaired» означає, що ZFS виправив пошкоджені дані за рахунок надмірності. Якщо виправлення тривають постійно — у вас постійна проблема (диск, кабелі, пам’ять, контролер).
Рішення: Якщо scrub завершується з помилками, розглядайте це як реальний інцидент, а не попередження. Зберіть zpool status -v і вирішіть, відновлювати файли чи замінювати апарат.
Завдання 16: Перерахуйте та оціни постійні помилки
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
errors: Permanent errors have been detected in the following files:
/tank/projects/db/base/16384/2609
/tank/projects/db/base/16384/2610Значення: ZFS каже: «Я знаю, які файли погані». Це подарунок. Для баз даних і образів VM ці шляхи важливі.
Рішення: Якщо це критичні файли: відновіть з бекапу/реплікації snapshot або відновіть/перебудуйте датасет/додаток. Не очікуйте, що ще один scrub «чарівно» виправить permanent errors.
Завдання 17: Перевірте, чи втрачено надмірність (недостатньо реплік)
cr0x@server:~$ sudo zpool status -v vault
pool: vault
state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.
config:
NAME STATE READ WRITE CKSUM
vault DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
ata-ST12000NM0008_A1 ONLINE 0 0 0
ata-ST12000NM0008_A2 ONLINE 0 0 0
15553461652766218490 UNAVAIL 0 0 0 was /dev/disk/by-id/ata-ST12000NM0008_A3
ata-ST12000NM0008_A4 ONLINE 0 0 0
ata-ST12000NM0008_A5 ONLINE 0 0 0
ata-ST12000NM0008_A6 ONLINE 0 0 0Значення: ZFS пам’ятає vdev за GUID і каже вам старий шлях. Це часто «диск відсутній» або «диск переенумерувався, але мітка зникла».
Рішення: Знайдіть відсутній диск (за серією, відсіком, шляхом HBA). Якщо диск присутній, але мітка зникла — це підозріло: щось її перезаписало. Не запускайте zpool replace, поки не знаєте, який фізичний диск відповідає GUID.
Завдання 18: Експортуйте пул чисто перед переміщенням дисків на інший хост
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import
no pools available to importЗначення: Export завершує та чисто закриває пул. Коли ви переміщуєте диски між хостами, це зменшує тертя «pool may be in use» і знижує ризик застарілого стану.
Рішення: Якщо машина достатньо стабільна, щоб експортувати — зробіть це. Якщо ні, плануйте read-only імпорт на хості для відновлення і документуйте причину.
Типові помилки: симптом → корінь → вирішення
Тут я врятую вас від вашого майбутнього себе. Це не теоретично. Це те, що люди роблять о 03:00, поки Slack кричить.
1) Пул не імпортується після «простого перезавантаження»
- Симптоми:
zpool importпоказує пул, але імпорт скаржиться, що «in use from other system» або зависає. - Корінь: Застарілий hostid, пул не було коректно експортувано, або пристрої флапають і імпорт зависає.
- Виправлення: Перевірте, що інші хости не мають імпортованого пулу. Зробіть примусовий імпорт лише для читання (
-f -o readonly=on -N) для огляду. Виправте проблеми шару пристроїв перед дозволом записів.
2) З’явилися «checksum errors» і хтось відразу заміняє диск
- Симптоми: Ненульовий CKSUM на vdev; пул деградований; scrub повідомляє помилки.
- Корінь: Може бути медіа-диск, але також пам’ять без ECC, HBA/бекплейн, поганий SAS кабель або баг прошивки. Замінити диск може не вирішити проблему і додати стрес під час resilver.
- Виправлення: Корелюйте: SMART-статус,
dmesg, лічильники помилок на кількох дисках і чи «переміщуються» помилки разом із кабелем/портом. Замінюйте апарат на підставі доказів, а не інтуїції.
3) Resilver «зависає» на низькій швидкості
- Симптоми:
zpool statusпоказує довгий час завершення resilver; пропускна здатність падає. - Корінь: Поведінка SMR‑дисків під випадковими записами, повторні читання через маргінальну медіа, пул навантажений записами, або один повільний пристрій у RAIDZ тягне vdev.
- Виправлення: Зменшіть навантаження, перевірте I/O помилки в журналах, тимчасово зупиніть інтенсивні записи, перевірте, щоб заміна не була повільнішою за решту. Якщо бачите повторні скидання — спочатку лагодьте кабелі/HBA.
4) Пул UNAVAIL після «оптимізації»
- Симптоми: Не вистачає special vdev, SLOG або metadata device; пул не монтує датасети; перед відмовою були дивні затримки.
- Корінь: Трактування «швидких пристроїв» як опціональних, коли вони були налаштовані як обов’язкові (special vdev — не те ж саме, що L2ARC). Або переповнення/незбалансованість.
- Виправлення: Замініть failed special vdev так само, як критичний диск. Проєктуйте special vdev з надмірністю. Не додавайте його, якщо не готові оперувати як критичною інфраструктурою.
5) Хтось запускає zpool labelclear на неправильному диску
- Симптоми: Раніше видимий vdev стає «відсутнім», пул деградує ще більше, вивід імпорту плутає.
- Корінь: Невірна ідентифікація фізичних дисків, покладання на
/dev/sdXабо пропуск кроку зіставлення серійників зі слотами. - Виправлення: Зупиніться. Зафіксуйте поточний вивід
zpool import. Відновіть мапу за серіями, WWN і інструментами шасі. Чистіть мітки лише коли точно впевнені, що диск не потрібен у жодному пулі.
6) Scrub «виправляє» те саме щоразу щотижня
- Симптоми: Scrub кожного разу виправляє невеликі обсяги; помилки контрольних сум переключаються між дисками; жоден диск не є постійним винуватцем.
- Корінь: Часто не диск: ненадійна пам’ять (особливо без ECC), проблеми HBA, кабелі, бекплейн або живлення.
- Виправлення: Розглядайте як проблему платформи. Запустіть тест пам’яті під час вікна обслуговування, перевірте журнали ECC, оновіть прошивку і провірте кабелі/бекплейн. Замінювати випадкові диски — дорого і марно.
Чеклісти / покроковий план
Чекліст A: Коли пул деградований, але онлайн
- Запустіть
zpool status -v. Визначте, чи помилки READ/WRITE/CKSUM і чи є «permanent errors». - Перевірте
dmesgна скидання/тайм-аути у той самий час. - Перевірте SMART/NVMe для підозрюваних пристроїв.
- Змепте пристрої по серіях/WWN до фізичних слотів.
- Якщо диск явно несправний: замініть його і моніторьте resilver.
- Після resilver: запустіть scrub пулу. Підтвердіть відсутність помилок.
- Лише потім: очистіть лічильники (
zpool clear) і поверніть робоче навантаження.
Чекліст B: Коли пул не імпортується
- Запустіть
zpool import(без аргументів) і збережіть вивід. - Переконайтесь, що ОС бачить всі очікувані пристрої (
ls -l /dev/disk/by-id/,lsblk). - Перевірте журнали ядра на предмет скидань/тайм-аутів.
- Якщо «in use from other system»: перевірте, що інші хости не імпортували пул; потім спробуйте read-only forced import:
zpool import -f -o readonly=on -N POOL. - Якщо пристрої відсутні: спочатку виправте апаратний шлях (кабелі/HBA/шасі), потім знову запустіть виявлення імпорту.
- Якщо імпорт вдалий у режимі лише для читання: змонтуйте вибірково і скопіюйте незамінні дані, перш ніж пробувати будь‑яке відновлення з дозволом запису.
Чекліст C: Коли підозрюєте корупцію
- Імпортуйте лише для читання і без монтування (
-o readonly=on -N), якщо можливо. - Запустіть
zpool status -vі знайдіть шляхи з permanent errors. - Прийміть рішення на рівні файлів: відновити/перебудувати/видалити похідні артефакти.
- Запускайте scrub лише коли пристрої стабільні.
- Якщо корупція повторюється: досліджуйте пам’ять, HBA, прошивки, живлення і кабелі. ZFS повідомляє симптоми; платформа постачає хворобу.
Три корпоративні міні-історії
Міні-історія 1: Інцидент через неправильне припущення
У них був сервер з дванадцятьма дисками в RAIDZ2, пара дзеркальних SSD для завантаження і акуратна таблиця відповідності відсіків до серійних номерів. Таблиця була «досить точна», що схоже на те, як сказати, що парашут «майже упакований».
Диск почав таймаутити. Інженер на виклику побачив /dev/sdj з помилками і витягнув «диск в слоті 10», бо так вказувала таблиця. Пул одразу погіршився. Тепер у RAIDZ2 vdev відсутні були два учасники: справжній проблемний диск і цілком здоровий диск, який витягли помилково.
Найстрашніше було те, як це виглядало нормально спочатку. ZFS не закричав інакше. Він просто перейшов з «деградований, але доступний» у «імпорт інколи не вдається», бо решта дисків опинились під великим навантаженням реконструкції, а оригінальний нестабільний лінк все ще флапав.
Відновлення зайняло більше часу, ніж потрібно, бо вони витратили години на дебати про команди ZFS. Виправлення було нудним: повернули на місце початковий підозрілий диск, перебудували коректну карту слотів зі шасі, а потім замінили реальний проблемний серійний номер. Після цього resilver завершився і пул відновився.
Постмортем: заборонити використовувати /dev/sdX в операціях і вимагати підтвердження серійних номерів перед витягом диска. Це не зробило нікого розумнішим. Це зробило наступний інцидент виживаним.
Міні-історія 2: Оптимізація, яка обернулась проти
Команда хотіла швидших операцій метаданих для мільйонів дрібних файлів. Вони додали special vdev на парі швидких SSD. Це спрацювало. Затримки впали, обходи каталогів стали миттєвими, і всі отримали свою «ми полагодили сховище» дозу дофаміну.
Через кілька місяців один SSD почав помилятися. Не фатально — інколи зникав під навантаженням. Пул не деградував як звичайне дзеркало. Метадаткове навантаження зробило special vdev центром всього, тому кожен спалах перетворювався на тайм‑аути в додатках.
Хтось під час інциденту запропонував: «Якщо це просто кеш, можемо від’єднати?» Ось де жили непорозуміння: special vdev — не кеш. Це може бути обов’язкове сховище для метаданих (і для маленьких блоків). Втрата — і пул може стати непридатним.
Відновлення було простим, але напруженим: стабілізували шлях пристрою (виявилось, маргінальний конектор бекплейну), замінили поганий SSD і відновили дзеркало special vdev. Після цього пул вернувся до нормальної продуктивності і стабільності.
Урок: якщо ви додаєте компонент оптимізації, який може вивести весь пул з ладу — це не оптимізація. Це новий рівень критичної інфраструктури. Працюйте з ним як з продакшеном.
Міні-історія 3: Нудна, але правильна практика, що врятувала
Одна команда робила тижневі scrubs, щомісячні тести відновлення і зберігала звички, що виглядали старомодно: після будь-якої зміни апаратури вони фіксували zpool status, zpool get all для ключових властивостей і інвентар пристроїв зі серіями та WWN. Це була паперова робота. Ніхто не вихвалявся.
Одного дня полиця зі сховищем перезавантажилась несподівано. ОС повернулась з іншим порядком нумерації пристроїв, і один шлях не відновився. Пул не імпортувався автоматично. Канал інцидентів почав формуватись, як хмари над пікніком.
Замість імпровізації вони дотримались плану. Порівняли поточний by-id інвентар з останнім зафіксованим знімком, точно визначили відсутній серійний номер і зіставили з журналами шасі. Це був не «мертвий диск» — це шлях SAS, що не зумів повторно зареєструватися після перезавантаження полиці.
Вони виправили шлях, знову запустили zpool import, імпортували в режимі лише для читання для перевірки, а потім імпортували нормальним способом. Ніяких -f, ніяких labelclear, ніякої магії. Аутедж був коротким, бо команда роками вкладала ресурси в нудні практики.
Жарт №2: Найкраща героїка у збереженні сховищ така нудна, що її ніхто не помічає — як вогнегасник, який ніколи не використали.
Цитата, яку варто мати у каналі інцидентів
Ідея Вернера Фогельса (парафраз): Усе постійно виходить з ладу; проєктуйте і експлуатуйте, припускаючи, що відмови — норма.
Рішення, що мають значення (і чому)
Імпорт лише для читання — це ваш клапан зниження тиску
Коли ви не впевнені у стабільності пристроїв, імпорт у режимі лише для читання дозволяє оглянути датасети, перевірити метадані і скопіювати дані без виконання нових записів. Це не ліки; це безпечніша діагностична поза.
Scrub — не перша допомога; це повне сканування
Scrub важкий. Він читає все. На пулі з маргінальним диском або хитким HBA scrubbing може перетворити «майже добре» на «тепер ми виявили кожен слабкий сектор одночасно». Це корисно, але не коли транспортний шар горить.
Швидкість resilver — це сигнал здоров’я, не просто метрика комфорту
Повільні resilver відбуваються з невинних причин (навантажений пул, поведінка SMR). Вони також трапляються, коли система виконує нескінченні повтори читань. Слідкуйте за скиданнями і I/O помилками в журналах; там правда.
Питання та відповіді
1) Чи варто перезавантажувати сервер ZFS, коли пул деградований?
Не як перший крок. Перезавантаження може змінити порядок пристроїв, втратити транзієнтний стан і перетворити флапаючий лінк на відсутній диск. Стабілізуйте апарат і зафіксуйте виводи перш ніж перезавантажувати.
2) Коли доречно використовувати zpool import -f?
Коли ви впевнені, що пул не імпортований десь ще і стан «in use» є застарілим (переміщення хосту, крах). Віддавайте перевагу -o readonly=on -N разом із -f при першому імпорті, якщо невпевнені.
3) Якщо SMART каже «PASSED», чи може диск усе ще бути поганим?
Так. «PASSED» часто — порогова перевірка. Pending сектори, uncorrectable і зростаючі CRC‑помилки — оперативні сигнали незалежно від загального результату.
4) Що насправді означають помилки контрольних сум?
ZFS прочитав блок, обчислив контрольну суму і вона не співпала з тією, що збережена. Погані дані могли надійти з медіа, кабелю, контролера, пам’яті або прошивки. Розглядайте це як доказ і корелюйте з іншими даними.
5) Чи одне й те саме scrub і resilver?
Ні. Scrub — це проактивна верифікація всіх даних. Resilver — це реконструкція на замінений або повернутий пристрій. Обидва роблять важкі читання; resilver також пише.
6) Чи можна просто від’єднати «cache» пристрій, щоб повернути пул?
Залежить від типу. L2ARC зазвичай можна видалити без втрати цілісності пулу. SLOG можна зазвичай видалити з певними зауваженнями. Special vdev може бути обов’язковим — не трактуйте його як кеш.
7) Чому ZFS показує довгий числовий ID замість імені пристрою?
Це GUID vdev. ZFS використовує його, щоб відстежувати учасників, навіть якщо шляхи пристроїв змінюються. Це підказка, що ZFS пам’ятає щось, чого ОС зараз не показує.
8) Який найбезпечніший спосіб перемістити пул на іншу машину для відновлення?
Експортуйте пул чисто, якщо можете, перемістіть диски, потім імпортуйте в режимі лише для читання з альтернативним коренем (-o readonly=on -R /mnt -N) для огляду перед дозвілом записів.
9) Якщо пул деградований, чи варто запускати zpool clear щоб «полагодити» його?
Ні. zpool clear скидає лічильники помилок. Корисно після виправлення основної проблеми, щоб перевірити, чи помилки повертаються. Воно не відновлює дані.
10) Як вирішити між «замінити диск» і «полагодити кабель»?
Дивіться на докази: CRC‑помилки і скидання лінку вказують на транспорт. Pending/uncorrectable сектори вказують на медіа. Якщо кілька дисків на тому ж HBA показують проблеми — підозрюйте спільний компонент.
Висновок: реальні наступні кроки
Якщо запам’ятаєте нічого іншого: стабілізуйте шар пристроїв, імпортуйте лише для читання, коли невпевнені, і ніколи не замінюйте диск, який не можете ідентифікувати точно. ZFS створено для виживання апаратних відмов. Він менше толерантний до імпровізацій.
Практичні наступні кроки для вашого середовища:
- Напишіть односторінковий on-call runbook, використовуючи «Швидку діагностику» і чеклісти вище.
- Переконайтесь, що кожен пул використовує стабільні шляхи пристроїв (by-id/WWN) і задокументуйте, як зіставляти серійні номери зі слотами.
- Заплануйте scrubs і налаштуйте алерти на нові помилки контрольних сум, а не лише на зміну стану пулу.
- Тестуйте відновлення. Не теоретично. На реальних даних. День, коли воно знадобиться — не час дізнаватися, що ваші бекапи — це перформанс‑арт.
- Аудитуйте будь‑які «оптимізаційні» vdev (special, SLOG) і переконайтесь, що вони мають надмірність і моніторяться як критичні компоненти.