Аварійні сценарії ZFS: що виходить з ладу першим і що можна зберегти

January 19, 2026 • February 3, 2026 • Читання: 6 хв • Views: 11

Було корисно?

ZFS рідко падає з феєрверком. Воно відмовляє як батарея в корпоративному ноутбуку: повільно, тихо й саме перед демо.
Спочатку пул переходить у стан DEGRADED, потім scrub починає «знаходити» проблеми, далі імпорт зависає, а ваш пейджер чемно
повідомляє, що сон тепер — це антикваріат.

Це польовий посібник для таких моментів. Не огляд можливостей. Карта скель: що зазвичай ламається першим, як швидко підтвердити проблему
і які дані ще можна врятувати — без класичного «виправив, видаливши все».

Як «падає» ZFS: стек відмов

ZFS — це не одинична річ. Це набір взаємопов’язаних обіцянок: контрольні суми, copy-on-write, транзакційна семантика, реплікація,
кешування й топологія зберігання, що змішує «диски» з «наміром». Коли система під навантаженням, ці обіцянки падають у передбачуваному
порядку.

1) Першим зазвичай виходить з ладу середовище, а не ZFS

У реальних інцидентів найперші відмови часто відбуваються поза пулом:

Електрика (просідання напруги, ненадійні блоки живлення, припущення про подвійне живлення)
Контролери (баґи прошивки HBA, скидання експандера, флапи SATA-підключення)
Пам’ять (без ECC плюс невдалий збіг; з ECC плюс збій DIMM)
Терміка (диски дають помилки через перегрів, відсічення швидкості або повне відключення)
Люди (найсумісніший компонент; працює з будь-якою системою)

2) Потім I/O: стрибки затримки → таймаути → «пристрій видалено»

ZFS консервативний. Коли vdev починає повільно чи непослідовно відповідати на I/O, ZFS віддає перевагу перестати йому довіряти. Так ви отримуєте пул,
який технічно ще онлайн, але практично непридатний: усе блокується на кількох вмираючих членах, логіка повторних спроб накопичується, а
додаток тлумачить це як «зберігання недоступне».

3) Метадані стають полем бою

Дані користувача часто переживають довше за цілісність метаданих. Якщо пул не може прочитати структури, що описують набори даних, снапшоти й
вказівники блоків, ваші «дані» стають складом без інвентарної системи. Тому спеціальні vdev і малі пристрої для метаданих мають більше значення,
ніж здається.

4) Нарешті руйнується довіра: помилки контрольних сум, які не відновлюються

Одна помилка контрольної суми — це попереджувальний постріл. Патерн невідновлюваних помилок контрольних сум — це сигнал від ZFS, що він не може знайти валідну копію.
У mirror/RAIDZ це зазвичай означає, що ви втратили забагато реплік або паритет не може відновити через більшу площу помилок, ніж резервність.

Парафраз ідеї Вернера Фогельса (CTO Amazon): «Все ламається весь час — проектуйте й експлуатуйте, як ніби це норма». ZFS допомагає,
але не скасовує закони фізики.

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

Поведінка ZFS під час аварій стає зрозумілішою, якщо пам’ятати, звідки воно прийшло і що було створено, щоб витримувати.

ZFS народився в Sun на початку 2000-х, щоб позбутися мовчазної корупції й болю адміністрування від розділення volume manager + filesystem.
Copy-on-write був ключовою ідеєю: ZFS записує нові блоки, а потім комітить вказівники, тож уникає «півзаписаних» структур після краху.
Контрольні суми — наскрізні: ZFS підраховує контрольні суми даних при збереженні, а не те, що диск «каже». Саме тому він виявляє «битий сектор», а не вгадує.
Scrub — не розкіш; це відповідь на реальну корупцію, яку класичний RAID охоче вважає «валідними» даними.
Модель пулу — бунт: замість розділення дисків на томи ви будуєте пул і виділяєте датасети. Адміни перестали грати в тетріс.
RAIDZ існує через write hole: класичний RAID5/6 може створювати неконсистентні смуги після втрати живлення; ZFS намагається уникнути цього транзакційними записами.
ARC/L2ARC відображає тодішню дорожнечу ОЗП: ARC у RAM, опціональний L2ARC на флеші, коли флеш здешевів достатньо.
OpenZFS став планом продовження після падіння Sun; нині це кросплатформовий проєкт з різними дефолтами й прапорами фіч залежно від ОС.

Що ламається першим: поширені аварійні сценарії

Сценарій A: Вихід одного диска в mirror/RAIDZ

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

Тут першим зазвичай втрачається продуктивність, а не коректність. Деградований vdev RAIDZ має менше паралелізму. Деградований mirror — це один диск до важкого вікенду.

Сценарій B: Кілька дисків виходять під час resilver

Небезпечне вікно — це не «вийшов диск». Небезпечне вікно — це «вийшов диск і тепер ми б’ємо решту дисків». Resilver і scrub — інтенсивні. Вони підвищують навантаження, нагрів і рівень помилок.
Диски, що були маргінальними, стають відверто поганими.

Що ламається першим: другі диски, часто з тієї самої партії, того самого віку, з однаковим профілем вібрації. Якщо ваша політика закупівель купує однакові диски в один день, вітання: ви створили синхронний відмовний дизайн.

Сценарій C: Скиди контролера/HBA, що викликають тимчасову втрату пристрою

ZFS реагує на зникнення пристроїв. Якщо контролер скинувся й усі диски на мить пропали, ZFS може позначити їх як недоступні.
Залежно від часу й поведінки ОС ви можете отримати:

Пул переходить у стан DEGRADED, бо один шлях флапнув
Пул переходить у стан SUSPENDED, бо помилки I/O перевищили пороги безпеки
Проблеми з імпортом після перезавантаження, бо імена пристроїв змінились

Що ламається першим: ваші припущення про «відмову диска». Диски можуть бути в порядку. Шина — ні.

Сценарій D: Втрата електропостачання + брехня write cache

ZFS транзакційний, але все одно покладається на стек зберігання, щоб виконувати flush. Якщо диск чи контролер підтверджує запис, який не було записано на фізичний носій, ви можете отримати пошкоджені журналні структурі намірів, неконсистентні метадані й пул, який імпортується, але поводиться ніби в нього струс мозку.

Якщо ви ставите sync=disabled на щось важливе, ви не оптимізуєте; ви граєте в рулетку з чиєюсь роботою.

Жарт №1: «sync=disabled» — це як зняти ремінь безпеки з авто, щоб покращити прискорення. Технічно правда, стратегічно сумнівно.

Сценарій E: Вихід special vdev (метадані/малі блоки)

Спеціальні vdev потужні й небезпечні. Якщо ви віддали метадані (і можливо малі блоки) на special vdev, ви створили залежність: втрата того vdev — втрата пулу.
Дзеркала допомагають, але радіус ураження реальний.

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

Сценарій F: Пул майже заповнений → фрагментація → «різкий» крах латентності

Найбільш нудні аварії — самозавдані. Пули понад ~80–90% заповнення (залежно від recordsize, навантаження й топології) фрагментуються.
Виділення стає дорогим. Записи посилюються. Затримки стрибкоподібні. Додатки таймаутять. Люди звинувачують «накладні витрати ZFS», поки пул намагається виділити блоки, наче пакує вантажівку без порожніх коробок.

Сценарій G: Тиск пам’яті й неправильно виставлений ARC у світі шумних сусідів

ZFS любить RAM. Ваша база даних теж любить RAM. Платформа контейнерів теж любить RAM. Коли вони б’ються, ядро виграє, вбиваючи когось.
ZFS під сильним тиском пам’яті може трешитись, викидаючи ARC, перейти на диск, збільшивши I/O і латентність — петля зворотного зв’язку, що закінчується тікетами «зберігання повільне».

Сценарій H: Втрата ключа шифрування

Вбудоване шифрування ZFS — хороша інженерія. Воно також безпощадне. Втратити ключ (або пароль + розташування ключа) — означає, що пул може бути цілком здоровим, а дані — абсолютно недоступні. Це не баг. Це контракт, який ви уклали.

Що можна врятувати (і що, ймовірно, ні)

Коли зазвичай можна врятувати все

Вихід одного диска у mirror/RAIDZ з оперативною заміною
Тимчасові помилки контролера, які не пошкодили метадані (пофіксувати шину, очистити, зробити scrub)
Помилки на рівні додатка, якщо є снапшоти (відкат/клон/відновлення)
Випадкові видалення, якщо існують снапшоти й їх не вичистили

Коли зазвичай можна врятувати дещо

Імпорт пулу в режимі тільки для читання, але при записах він падає або зависає: часто можна zfs send критичних наборів даних назовні
Деякі невідновлювані помилки контрольних сум: іноді можна скопіювати неуражені набори даних або файли, а потів відбудувати пул
Пошкодження метаданих, обмежене кількома наборами: інші набори можуть змонтуватись; пріоритезуйте експорт одразу

Коли ви в основному рятуєте логи й уроки

Спеціальний vdev втрачен без резервності: пул зазвичай непрактично не відновлюваний
Втрачено більше членів vdev, ніж дозволяє резервність (наприклад, RAIDZ1 з двома відмовами)
Ключі шифрування пішли (немає ключа — немає доступу до даних)

Жарт №2: Відновлення даних без бекапів — як намагатися зробити незгорілий тост викруткою. Ви можете бути дуже зайняті й усе одно дуже голодні.

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

Найшвидший шлях до тями — відокремити здоров’я пулу, здоров’я пристроїв і вузьке місце продуктивності.
Не починайте з героїки. Почніть з фактів.

Перший: Чи безпечно торкатися пулу?

Перевірте стан пулу: zpool status -xv і zpool list. Якщо ви бачите SUSPENDED, зупиніться й стабілізуйте систему.
Підтвердіть, що не закінчилося місце: zfs list -o name,used,avail,refer,mountpoint. Пули на 95% заповнення створюють «таємничі відмови».
Перевірте активність resilver/scrub: статус підкаже; якщо це триває під час інциденту, подумайте про паузу для конкурентних навантажень.

Другий: Це відмова диска, шини чи софту?

Подивіться dmesg/journal на предмет скидів лінку й таймаутів (SATA/SAS sense errors, NVMe resets).
Перевірте SMART/NVMe-здоров’я для пристроїв, на які скаржиться ZFS. Один поганий диск реалістичний; вісім «поганих дисків» одночасно — зазвичай контролер.
Перевірте стабільність ідентифікаторів пристроїв (шляхи by-id). Якщо імена дисків змінились, імпорт може бути дивним.

Третій: Швидко знайдіть вузьке місце

I/O латентність: zpool iostat -v 1 — знайдіть vdev з високим wait і низькою пропускною спроможністю.
ARC‑тиск: якщо ARC малий і промахи високі, ви йдете на диск.
Тиск на синхронні записи: якщо у вас є SLOG і він повільний або мертвий, синхронні навантаження повільнітимуть.

Практичні завдання: команди, значення виводу й рішення

Це «зроби це о 03:17» завдання. Кожне містить, на що дивитись і яке рішення має зумовити. Команди припускають Linux з OpenZFS; підлаштовуйте під платформу, але зберігайте логіку.

Завдання 1: Підтвердити, чи щось взагалі зламано

cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Значення: ZFS не бачить проблем на рівні пулу. Ваш відмовний випадок ймовірно вище ZFS (додаток, мережа) або нижче нього (апарат, що створює латентність без помилок).
Рішення: Перейдіть до тріажу продуктивності (zpool iostat, ARC і системні метрики) замість негайної заміни диска.

Завдання 2: Прочитати реальну історію пулу, а не заспокійливу підсумок

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.  Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 02:11:45 with 3 errors on Thu Dec 26 01:02:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     1
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
/tank/data/db/index/segments_12

Значення: Пул доступний, але принаймні один блок не вдалось реконструювати і файл пошкоджено.
Рішення: Розглядайте це як інцидент цілісності даних, а не тільки апаратну проблему. Відновіть файл з реплікації додатка або з бекапу; після цього запустіть scrub і подумайте про заміну диска з помилками CKSUM.

Завдання 3: Визначити, чи «READ/WRITE/CKSUM» вказує на диск, кабель чи пам’ять

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
            sda     ONLINE       0     0    12
            sdb     ONLINE       0     0     0

Значення: CKSUM-помилки на sda свідчать про погані читання з цього шляху пристрою. Це може бути диск, кабель/бекплейн або пам’ять під час читань (рідше з ECC).
Рішення: Запустіть SMART і подивіться логи ядра для sda; якщо видно скиди лінку, підозрюйте кабелі/HBA. Якщо SMART показує перераспреділ/очікуючі сектора — замінюйте диск.

Завдання 4: Перевірити, чи пул не душить себе через заповненість

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,health
NAME   SIZE   ALLOC   FREE  FRAG  HEALTH
tank  43.5T   40.9T  2.6T   73%  ONLINE

Значення: 73% фрагментації з малою вільною пам’яттю — пастка для продуктивності.
Рішення: Припиніть сперечатися про тюнінги і створіть простір. Видаліть старі снапшоти, перемістіть холодні дані, або розширіть пул. Якщо навантаження багато випадкових записів, подумайте про додавання vdev, а не про поодиноку заміну дисків на більші.

Завдання 5: Знайти гарячий vdev під навантаженням

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        40.9T  2.6T     210    980  34.1M  112M
  raidz2-0  40.9T  2.6T     210    980  34.1M  112M
    sda         -      -      35    165  5.6M   19M
    sdb         -      -      36    164  5.5M   19M
    sdc         -      -      34    166  5.7M   18M
    sdd         -      -      35    321  5.5M   37M
    sde         -      -      35      0  5.6M     0
    sdf         -      -      35    164  5.6M   19M

Значення: Один диск (sdd) отримує непропорційно багато записів; це може бути нормальний розподіл, повторні спроби або проблема шляху.
Рішення: Зіставте з лічильниками помилок у zpool status і логами ядра. Якщо один диск має високу латентність/таймаути, замініть або переустановіть його.

Завдання 6: Підтвердити, чи ZFS гальмує через помилки (suspended I/O)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: SUSPENDED
status: One or more devices are faulted in response to persistent errors.
action: Make sure the affected devices are connected, then run 'zpool clear'.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     FAULTED     75     0     0  too many errors

Значення: ZFS зупинив I/O, щоб запобігти подальшим ушкодженням або зависанням.
Рішення: Не «clear і молитися» повторно. Виправте основну проблему пристрою/шляху спочатку (замініть диск, полагодьте HBA/бекплейн), потім zpool clear і scrub.

Завдання 7: Перевірити ідентичність пристрою, щоб не замінити не той диск

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sdc|WDC|SEAGATE' | head
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sdc

Значення: Ви можете зіставити логічні імена пристроїв зі стабільними ID.
Рішення: Використовуйте шляхи by-id при заміні та в документації. Якщо ваш runbook каже «замінити sdc», оновіть runbook; він бреше після перезавантаження.

Завдання 8: Перевірити SMART на маркери «вмирає»

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep 'Reallocated|Pending|Offline_Uncorrectable|CRC|SMART overall'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       12
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       -       0

Значення: «PASSED» не означає формального дозволу. Очікуючі та некориговані сектора — реальна проблема.
Рішення: Замініть диск. Якби CRC-помилки були високими, спочатку підозрюйте кабелі/бекплейн.

Завдання 9: Замінити відмовлений пристрій безпечно

cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-WDC_WD80_BAD /dev/disk/by-id/ata-WDC_WD80_NEW
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
scan: resilver in progress since Thu Dec 26 01:22:01 2025
        1.23T scanned at 2.10G/s, 412G issued at 703M/s, 40.9T total
        412G resilvered, 0.98% done, 16:10:12 to go

Значення: Resilver почався; оцінка часу часто оптимістична художня вигадка.
Рішення: Зменшіть навантаження, якщо можете. Слідкуйте за додатковими помилками. Якщо під час resilver інші диски починають показувати помилки, припиніть удавати, що це одинична відмова, і переоцініть апаратну частину.

Завдання 10: Підтвердити поведінку 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 02:01:44 2025
        7.88T scanned at 1.05G/s, 1.12T issued at 153M/s, 40.9T total
        0B repaired, 2.74% done, 06:12:10 to go

Значення: Scrub перевіряє контрольні суми. «0B repaired» поки що добре; якщо в кінці буде repaired >0 і без permanent errors, резервність спрацювала.
Рішення: Якщо scrub знаходить permanent errors, визначте уражені файли й відновіть з снапшоту/бекапу. Не ігноруйте «лише кілька» помилок контрольних сум.

Завдання 11: Проблеми з монтуванням — подивіться, що ZFS вважає змонтованим

cr0x@server:~$ zfs list -o name,mounted,mountpoint,canmount
NAME                 MOUNTED  MOUNTPOINT     CANMOUNT
tank                 yes      /tank          on
tank/data             no      /tank/data     on
tank/data/db          no      /tank/data/db  on

Значення: Датасети присутні, але не змонтовані. Причиною може бути відмова залежностей, шифрування заблоковане або конфлікт mountpoint.
Рішення: Перевірте стан шифрування і помилки в zpool status та системних логах. Спробуйте явне mount і зафіксуйте помилку.

Завдання 12: Тріаж шифрування — чи можна завантажити ключі?

cr0x@server:~$ zfs get -H -o name,property,value encryption,keylocation,keystatus tank/data
tank/data	encryption	aes-256-gcm
tank/data	keylocation	file:///root/keys/tank_data.key
tank/data	keystatus	unavailable
cr0x@server:~$ sudo zfs load-key -a
Enter passphrase for 'tank/data': 
cr0x@server:~$ zfs get -H -o name,property,value keystatus tank/data
tank/data	keystatus	available

Значення: Датасет був зашифрований і заблокований; тепер розблоковано.
Рішення: Якщо не вдається завантажити ключі — зупиніться. Не руйнуйте й не пересоздавайте нічого. Ваш інцидент тепер — «керування ключами», а не «надійність зберігання».

Завдання 13: Безпечно імпортувати пул після краху (спочатку тільки для читання)

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          raidz2-0  ONLINE
            sda     ONLINE
            sdb     ONLINE
            sdc     ONLINE
            sdd     ONLINE
            sde     ONLINE
            sdf     ONLINE
cr0x@server:~$ sudo zpool import -o readonly=on tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
status: The pool is imported in read-only mode.

Значення: Ви імпортували пул без дозволу на запис. Це зменшує ризики під час оцінки.
Рішення: Якщо підозрюєте корупцію, тримайте в режимі read-only і починайте витяг критичних наборів через zfs send або копіювання файлів на безпечний носій.

Завдання 14: Знайти останні зміни (снапшоти, утримання, клони)

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation | head
NAME                         CREATION
tank/data@auto-2025-12-26-0100  Thu Dec 26 01:00 2025
tank/data@auto-2025-12-26-0000  Thu Dec 26 00:00 2025
tank/data@auto-2025-12-25-2300  Wed Dec 25 23:00 2025

Значення: У вас є свіжі снапшоти; добре. Якщо ні — ваш майбутній «я» матиме серйозну розмову з вами.
Рішення: Якщо інцидент — «погане розгортання видалило щось», відновіть зі снапшоту (клон або rollback). Якщо інцидент — корупція, використайте снапшоти для zfs send на новий пул.

Завдання 15: Реплікуйте назовні найцінніші дані першими

cr0x@server:~$ sudo zfs send -v tank/data@auto-2025-12-26-0100 | sudo zfs receive -u rescue/data
send from @auto-2025-12-26-0100 estimated size is 3.12T
total estimated size is 3.12T
TIME        SENT   SNAPSHOT
00:00:10   5.28G   tank/data@auto-2025-12-26-0100

Значення: Ви стримуєте консистентний снапшот у rescue-пул/датасет, а не намагаєтесь «фіксити на місці».
Рішення: Якщо бачите помилки send — зафіксуйте датасет і змініть пріоритет. Часто можна врятувати інші датасети, навіть якщо один пошкоджений.

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

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія тримала платформу VM на ZFS. Два вузли з пулом RAIDZ2. Реплікація була, але «на краще зусилля».
Припущення команди — ніколи не записане, але постійно повторюване — було, що RAIDZ2 означає «ми можемо втратити два диски і все буде гаразд».

Одного п’ятниці пул став DEGRADED. Диск замінили. Почався resilver. Під час resilver другий диск почав логувати таймаути.
Усі були спокійні: «Ми ще в межах RAIDZ2». Потім контролер скинувся. Усі диски на мить пропали, повернулись і ZFS позначив третій пристрій як faulted через накопичені помилки. Пул від «в порядку» до SUSPENDED став за мить.

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

Відновлення не було героїчним. Вони імпортували read-only, негайно почали zfs send найважливіших VM-датасетів на інший вузол
і погодились, що деякі низькоприорітетні VM доведеться відновити зі зображень пізніше. Виправлення було нудне: нова прошивка HBA, дисципліна з кабелями
і політика «будь-яка аномалія з кількома дисками — шина перш за все, поки не доведено протилежне».

Міні-історія 2: Оптимізація, що зіграла злий жарт

Інша команда тримала latency-sensitive NFS на ZFS. Вони провели бенчмарк, побачили великі виграші, відключивши sync, і запустили це в продакшн.
Обґрунтування звучало розумно: «Додаток вже стійкий, у нас є UPS».

Місяцями потому стався електроподієвий інцидент. Не повний відключ — просто просідання, через яке один вузол перезавантажився. Пул імпортувався. Сервіси стартували.
Користувачі помітили дивну корупцію файлів: маленьку, випадкову, нерепродуковану. Така проблема, що змушує всіх сумніватися в реальності.

Що сталося: «sync disabled» дозволив системі підтверджувати записи до того, як вони стали стійкими. UPS не допоміг, бо режим відмови був не «вимкнення живлення», а «непередбачувана поведінка апаратури через нестабільну напругу». ZFS виконав угоду, яку йому наказали; угоду було переписано прапором налаштування.

Виправлення було болючим, але простим: відновити уражені датасети зі справних снапшотів і реплікації, знову ввімкнути sync і додати SLOG,
відповідно розмірений і специфікований для стабільних синхронних записів. Урок закріпився. Вони досі бенчмаркать, але бенчмарк справжнього навантаження, а не фантазії.

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

SaaS-провайдер мав пул ZFS для завантажень клієнтів і внутрішніх артефактів збірки. Дані не були «питанням життя і смерті», але їх втрата створювала велике число дрібних проблем.
Вони робили щотижневі scrubs і щоденну реплікацію снапшотів на окрему систему. Жодного драматичного шоу, жодних слайдів для керівництва. Просто планове обслуговування по календарю.

Одного тижня scrub повідомив кілька помилок контрольних сум, які були відремонтовані. On-call інженер все одно зареєстрував тікет, бо «repaired» — не те саме, що «ок». SMART показав диск з ростом очікуючих секторів. Диск було замінено в робочий час. Ніхто не помітив.

Через два тижні інший диск в тому ж шасі вийшов під час пікового навантаження. Почався resilver. Ще один диск почав хитатись. Тоді справді існувала загроза перевищення меж резервності, якби все погіршилось.

Команда не грала в півдню. Вони зменшили навантаження, тимчасово зупинили несуттєві записи і підтвердили свіжість реплікації. Коли пул пережив, чудово. Якби ні — вони вже були готові до failover. «Нудна практика» була не лише scrub; це план зупинити копання далі, коли яма стає глибокою.

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

1) Симптом: Пул ONLINE, але все повільно

Корінь проблеми: Пул майже повний + фрагментація; або повільний/вмираючий пристрій, що створює чергу.
Виправлення: Перевірте zpool list на вільне місце/frag; запустіть zpool iostat -v 1 щоб знайти відстаючий пристрій; звільніть місце і замініть/займіться повільним членом.

2) Симптом: Багато дисків «виходять» одночасно

Корінь проблеми: Скидання HBA, експандер/бекплейн, проблема з живленням або кабелюванням.
Виправлення: Перегляньте системні логи на предмет скидів лінку/таймаутів; переустановіть/замініть HBA або бекплейн; не міняйте диски «розкидно», поки не доведете, що вони погані.

3) Симптом: Зростають CKSUM-помилки, SMART виглядає чистим

Корінь проблеми: Цілісність шляху (кабелі), проблеми контролера або корупція пам’яті.
Виправлення: Перевірте UDMA CRC counters, переустановіть кабелі, протестуйте пам’ять, переведіть диск на інший порт/контролер і подивіться, чи йдуть помилки за диском чи за шляхом.

4) Симптом: Scrub знаходить «permanent errors»

Корінь проблеми: ZFS не може реконструювати принаймні один блок із доступної резервності.
Виправлення: Відновіть уражені файли/датасети зі снапшотів/бекапів/реплік; після відновлення запустіть scrub ще раз. Розглядайте як інцидент цілісності даних.

5) Симптом: Імпорт зависає або триває вічно

Корінь проблеми: Один або декілька пристроїв таймаутять; надзвичайно повільні читання під час replay; масивна метадата churn.
Виправлення: Імпортуйте в режимі read-only; ізолюйте відмовні диски (SMART/логи); спробуйте імпортувати на системі з відомими хорошими HBA; пріоритезуйте експорт критичних даних.

6) Симптом: Датасет не монтується після ребута

Корінь проблеми: Ключ шифрування не завантажений; конфлікт mountpoint; canmount=off; або пошкоджені/заблоковані властивості датасету.
Виправлення: Перевірте zfs get keystatus, zfs list -o mounted,canmount,mountpoint, виправте ключі/властивості; змонтуйте явно і зафіксуйте помилку.

7) Симптом: Resilver надзвичайно повільний

Корінь проблеми: Важке конкурентне навантаження; SMR-диски; повільний диск-замінник; mismatch ashift; вузьке місце контролера.
Виправлення: Зменшіть навантаження, перевірте тип диска, подивіться zpool iostat для пропускної здатності по дисках; не «оптимізуйте» піднімаючи параметри наосліп — знайдіть лімітатор.

8) Симптом: Все померло після додавання special vdev

Корінь проблеми: Special vdev не мав резервності або не моніторився; він впав і взяв з собою метадані.
Виправлення: Якщо він втрачен, опції відновлення обмежені. Запобігайте цьому наступного разу: дзеркаліть special vdev, моніторте як за роботою, що визначає вашу роботу, і ставтесь до них як до tier-0 пристроїв.

Чек-листи / покроковий план

Чек-лист: Коли пул стає DEGRADED

Збережіть вивід zpool status -v для інцидентного запису.
Перевірте, чи йде resilver/scrub; вирішіть, чи зменшити навантаження.
Підтвердіть місткість/фрагментацію: zpool list, zfs list.
Зіставте імена пристроїв зі by-id та фізичними слотами перед будь-якими апаратними діями.
Отримайте SMART/NVMe-стан і перевірте системні логи на скиди лінку.
Замінить відмовний компонент (диск проти кабелю проти HBA) на підставі доказів.
Моніторьте resilver; слідкуйте за новими помилками на інших членах.
Запустіть scrub після завершення resilver.
Якщо повідомлені permanent errors: відновіть уражені файли/датасети з відомих джерел.

Чек-лист: Коли ви бачите permanent checksum errors

Якщо можливо, зупиніть запис; розгляньте імпорт у режимі read-only якщо безпечно перезавантажитись.
Визначте уражені файли через zpool status -v.
Вирішіть джерело відновлення: снапшоти, реплікація, відбудова на рівні додатка або бекапи.
Відновіть і перевірте цілісність (перевірки додатка, хеші або специфічна валідація).
Запустіть scrub знову; якщо помилки зберігаються, підозрюйте додаткові приховані ушкодження і плануйте міграцію пулу.

Чек-лист: Коли продуктивність колапсує, але здоров’я виглядає добре

Перевірте заповненість пулу та фрагментацію.
Запустіть zpool iostat -v 1 і знайдіть найповільніший диск/vdev.
Перевірте тиск синхронних записів і стан SLOG (якщо є).
Перевірте тиск пам’яті і свапінг; «повільність» зберігання може бути війною за RAM.
Пошукайте фонові активності: scrub/resilver, destroy snapshot, отримання реплікації.
Виправляйте вузьке місце, яке можете довести. Не налаштовуйте наосліп.

FAQ

1) Що насправді ламається першим у більшості аварій ZFS?

Середовище: живлення, контролери, кабелі або людські зміни. ZFS часто лише посланець, який відмовляється брехати.

2) Чи завжди помилки контрольних сум означають мертвий диск?

Ні. Це може бути медіа-диск, але також кабелі/бекплейн, проблеми контролера або корупція пам’яті. Використовуйте SMART плюс логи ядра, щоб розділити причини.

3) Чи варто scrub запускати під час інциденту?

Якщо пул стабільний, але ви підозрюєте приховану корупцію, scrub — діагностичний і коригуючий інструмент. Якщо апарат активно відмовляє, scrubbing може пришвидшити крах. Спочатку стабілізуйте.

4) Чи RAIDZ2 «достатньо безпечний» для великих дисків?

Він безпечніший за RAIDZ1, але безпека залежить від часу відновлення, навантаження і корельованих відмов. Дзеркала відновлюються швидше; RAIDZ економить місце. Вибирайте за цілями відновлення, а не за таблицею в електронній формі.

5) Чи можна імпортувати пул у режимі read-only, щоб врятувати дані?

Так, і часто так і треба. zpool import -o readonly=on зменшує ризик під час оцінки й вилучення даних.

6) Який найменш відновлюваний режим відмов ZFS?

Втрата ключів шифрування — абсолютна. Втрата нерезервного special vdev близько за ступенем. У обох випадках пул може бути «здоровим», але непридатним.

7) Чи робить додавання SLOG пул безпечнішим?

Воно може зробити синхронні записи швидшими і передбачуванішими. Але не замінює бекапи, а поганий SLOG може стати проблемою продуктивності чи надійності, якщо неправильно підібраний.

8) Чому ZFS сповільнюється, коли пул майже повний?

ZFS виділяє блоки по вільному простору; коли вільного місця мало й воно фрагментоване, виділення стає дорогим, і записам притаманна ампліфікація. Виправлення — більше місця, а не надія.

9) Чи варто коли-небудь використовувати `sync=disabled`?

Лише коли втрата даних прийнятна і на це є явна згода. Для більшості продакшн-систем це фатальний гачок із приємним результатом бенчмарку.

10) Чи можна «clear» помилки і продовжити?

Можна очистити лічильники, але не реальність. Якщо помилки були транзиторними і scrubs чисті — гаразд. Якщо помилки продовжують зростати — ви маскуєте живу несправність.

Наступні кроки, які можна виконати цього тижня

Якщо ви хочете менше аварій ZFS — робіть менше магії і більше рутини. ZFS винагороджує нудну компетентність.

Заплануйте scrubs і переглядайте результати, ніби вони важливі. Вони важливі.
Встановіть політику заміни на основі трендів SMART і віку, а не лише на відмовах.
Перейдіть на стабільні імена пристроїв (by-id) у конфігураціях пулу й runbook.
Протестуйте імпорт у read-only і відновлення зі снапшоту на непродукційному клоні. Не чекайте інциденту, щоб виявити, що бекап був «теоретичним».
Зробіть управління простором першим класом метрикою: налаштуйте алерт при >80–85% заповнення та аномалії росту снапшотів.
Аудитуйте special vdev і log-пристрої: переконайтеся в резервності, моніторингу та відповідному обладнанні.
Запишіть порядок тріажу (здоров’я пулу → стан пристрою/шляху → вузьке місце продуктивності) і зробіть його обов’язковим для on-call.

Мета не в тому, щоб ніколи не бачити DEGRADED. Мета — бачити це рано, реагувати спокійно і ніколи не відчувати в собі, що таке «permanent errors» на власному досвіді.

Схожі статті

Тренування DR із ZFS send/receive: відпрацьовуємо відновлення, а не лише резервні копії ZFS: шифрування і стиснення — порядок, що визначає продуктивність ZFS: заміна кількох дисків — безпечний порядок, що запобігає відмові