Пошкоджені мітки ZFS: правильне виправлення помилок імпорту

February 2, 2026 • February 3, 2026 • Читання: 7 хв • Views: 10

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

Є мало збоїв у зберіганні даних, які так дратують, як пул ZFS, що раніше працював, а тепер відмовляється імпортуватися. Сервер завантажується, диски крутяться, а ZFS дивиться вам в очі і каже: «ні». Повідомлення різняться — пошкоджені мітки, відсутні vdev, некоректні GUID — але результат однаковий: ваші сервіси впали, а шлунок виконує власний «resilver».

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

Що таке мітки ZFS (і що насправді означає «пошкоджено»)

ZFS не зберігає єдиний «суперблок» в одному крихкому місці. Він записує критичну конфігурацію пулу та ідентифікаційні дані пристрою у чотири мітки на кожен vdev: дві на початку диска (або розділу) і дві в кінці. У цих мітках ви знайдете, наприклад:

GUID та ім’я пулу
GUID vdev та топологію
Вказівники на групи транзакцій (TXG), які показують «де зараз істина»
Uberblocks: набір контрольних точок, що дозволяють ZFS знайти найсвіжішу узгоджену стан

Коли ZFS каже, що мітка пошкоджена, це може означати кілька різних речей:

Контрольна сума мітки не проходить перевірку (фактичне пошкодження).
Пристрій не містить очікуваних GUID пулу/vdev (неправильний диск, застарілий диск або змінився мапінг пристроїв).
Читаються лише деякі мітки (часткове ушкодження, проблеми на краю диска, особливості шасі).
Мітка в порядку, але решта дерева метаданих посилається на блоки, які не читаються (глибша проблема вводу/виводу, що проявляється як проблема з мітками/uberblock).

Ще один нюанс, який часто пропускають під стресом: імпорт ZFS — операція, що інтенсивно читає. Імпорт може не вдатися через тайм-аути читання, а не через логічну некоректність метаданих. Шлях, який «нібито працює» при легкому навантаженні, може розвалитися, коли ZFS сканує мітки, читає uberblocks і намагається відкрити кожен vdev. Тому, коли бачите «пошкоджена мітка», не тягніться одразу до руйнівних інструментів. Спочатку доведіть, який саме тип «пошкодження» перед вами.

Цікавинки та історичний контекст

Мітки ZFS мають надлишковість за замовчуванням: чотири на vdev. Загубити одну — це звично; загубити всі чотири зазвичай вказує на серйозну проблему з I/O або перезапис.
Ранні проєкти ZFS уникали єдиних точок відмов: мульти-міткова архітектура — частина філософії «без суперблоку», що формувала ZFS з самого початку.
Ідентичність пулу базується на GUID, а не на імені: ім’я пулу — зручне для людини; GUID — те, чому довіряє ZFS.
Шляхи пристроїв нестабільні: «/dev/sda» завжди була поганою ідеєю для продукційних пулів. Персистентні шляхи, як by-id, існують, бо світ хаотичний.
Сучасний ZFS зберігає кілька uberblock: він може відкотитися до попереднього узгодженого стану, коли найновіший TXG нечитаємий.
Поведінка імпорту еволюціонувала: прапори на кшталт -F (rewind) і можливості на кшталт checkpoints з’явилися через реальні падіння систем і необхідність безпечних запасних сценаріїв.
Реальність 4K секторів вдарила сильно: помилки ashift (наприклад, 512e vs 4Kn) викликали ситуації, коли пул «працював», поки не замінили диск — і все раптом перестало співпадати.
HBА та експандери можуть брехати: транзитні ресети лінків і баги прошивки шасі історично маскувалися під корупцію.
ZFS консервативний при імпорті: він краще відмовиться імпортувати, ніж зробить це так, щоб спричинити приховані пошкодження.

Режими відмов при імпорті: що має значення

1) Справжнє пошкодження мітки (перезапис або ушкодження носія)

Це трапляється, коли щось записує на початок/кінець пристрою (неправильний інструмент для розділів, помилкове «wipefs», невдалий dd, контролер RAID ініціалізує метадані), або коли диск не може надійно читати ці області. У випадку перезапису це часто раптово і тотально: ZFS взагалі не може ідентифікувати vdev. У випадку з носієм це може бути переривчасто: мітки читаються під час одного завантаження, але не під час наступного.

2) Невірний мапінг пристроїв (класика)

Імена пристроїв змінюються. Порядок контролерів змінюється. Multipath напівналаштований. Хтось перемістив диски між шельфами. ОС тепер представляє диски інакше, і ZFS не може знайти те, чого очікує. Це виглядає як корупція, бо ZFS бачить диски, але мітки, які він читає, не належать пулу, який ви намагаєтеся імпортувати.

3) Відсутні vdev (втрачений диск у RAIDZ не «опційний»)

Міррори часто можуть продовжувати працювати з відсутнім членом. RAIDZ vdev ж більш вибагливі: відсутній диск може завадити імпорту в залежності від надлишковості і від того, який саме диск відсутній. Також: якщо пул створювали з розділами, а тепер диск показується як цілий пристрій, ZFS може не зіставити його.

4) Збій I/O шляху, що маскується під проблему метаданих

Імпорт потребує читань по всій топології. Непевний SAS-кабель, нестабільне живлення, проблеми експандера або несправний HBA можуть перетворитися на помилки «пошкодженої мітки», бо читання таймаутяться або повертають сміття. Тут ви перестаєте вірити в софтверні фікси й починаєте дивитися на апарат, наче він винен вам гроші.

5) Невідповідність прапорів/версії функцій (рідше, але буває)

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

6) Ви імпортували не той пул (таке трапляється)

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

Жарт #1: Найшвидший спосіб виявити, що у вас неповний інвентар — спробувати імпортувати пул ZFS під час аварії.

Швидкий план діагностики

Це послідовність «не заблукати». Мета — швидко знайти вузьке місце: неправильні пристрої, відсутні пристрої або несправний I/O.

Спочатку: підтвердіть, що бачить ZFS, нічого не змінюючи

Перелічіть імпортовані пулі (zpool import).
Спробуйте імпорт лише для читання, якщо пул видимий (zpool import -o readonly=on).
Зафіксуйте помилки дослівно. Не переказуйте їх з пам’яті. Ваша пам’ять — не лог.

По-друге: підтвердіть стабільність ідентичності пристроїв

Використовуйте персистентні шляхи: /dev/disk/by-id (Linux) або стабільні вузли пристроїв у вашій ОС.
Зіставте серійні номери з відсіками/шасі (через lsblk, udevadm, smartctl).
Переконайтеся, що кожен очікуваний диск присутній і ОС може читати його без помилок.

По-третє: перевірте на помилки вводу/виводу та тайм-аути

Подивіться журнали ядра на предмет ресетів і тайм-аутів (dmesg, journalctl).
Запустіть швидкі SMART-перевірки і перевірте лічильники помилок.
Якщо читання не вдаються, зупиніть «хірургію ZFS» і спочатку виправте апаратний шлях.

По-четверте: перевірте мітки безпосередньо

Використовуйте zdb -l проти кандидатних пристроїв, щоб побачити GUID пулу/vdev.
Порівняйте знайдене з тим, що очікує імпорт.

По-п’яте: лише потім пробуйте відкат/відновлення імпорту

Спочатку спробуйте імпорт для читання.
Використовуйте -F (rewind) обережно і розумійте, що буде відкинуто.
Користуйтеся екстремальними прапорами лише коли можете пояснити радіус ураження.

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

Це польові кроки. Кожне завдання містить команду, приклад виводу, що це означає і як ви ухвалюєте рішення. Припустимо Linux з OpenZFS, якщо не вказано інше.

Завдання 1: Перелічити пулі, які ZFS вважає доступними

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

        tank                          ONLINE
          mirror-0                    ONLINE
            ata-ST8000VN004-2M2101_ZA1A2B3C  ONLINE
            ata-ST8000VN004-2M2101_ZD4E5F6G  ONLINE

   pool: prod
     id: 1692242210959834013
  state: FAULTED
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
   see: zpool(8)
 config:

        prod                          FAULTED  corrupted data
          raidz2-0                    FAULTED
            ata-WDC_WD120EMFZ-11A6JA0_9HGK1AAA  UNAVAIL  invalid label
            ata-WDC_WD120EMFZ-11A6JA0_9HGK2BBB  ONLINE
            ata-WDC_WD120EMFZ-11A6JA0_9HGK3CCC  ONLINE
            ata-WDC_WD120EMFZ-11A6JA0_9HGK4DDD  ONLINE
            ata-WDC_WD120EMFZ-11A6JA0_9HGK5EEE  ONLINE
            ata-WDC_WD120EMFZ-11A6JA0_9HGK6FFF  ONLINE

Що це означає: ZFS бачить пул з іменем prod, але один пристрій має статус UNAVAIL invalid label. Це або відсутній диск, неправильний пристрій, або мітка, яку не можна прочитати.

Рішення: Не виконувати zpool import -f поки що. Спочатку перевірте, що диск існує і його можна прочитати на рівні ОС, а потім інспектуйте мітки.

Завдання 2: Спробувати імпорт лише для читання (безпечний перший крок)

cr0x@server:~$ sudo zpool import -o readonly=on prod
cannot import 'prod': one or more devices is currently unavailable

Що це означає: Імпорт для читання не обходить вимоги щодо відсутніх vdev. Пул все ще не може зібратися.

Рішення: Визначити відсутній/недоступний пристрій і чи він справді зник чи просто неправильно ідентифікований.

Завдання 3: Перевірити, що ОС бачить очікувані блочні пристрої

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,TYPE | sed -n '1,12p'
NAME   SIZE MODEL              SERIAL      WWN                TYPE
sda  10.9T WDC WD120EMFZ-11A6  9HGK2BBB    0x50014ee2b1a2b222  disk
sdb  10.9T WDC WD120EMFZ-11A6  9HGK3CCC    0x50014ee2b1a2b333  disk
sdc  10.9T WDC WD120EMFZ-11A6  9HGK4DDD    0x50014ee2b1a2b444  disk
sdd  10.9T WDC WD120EMFZ-11A6  9HGK5EEE    0x50014ee2b1a2b555  disk
sde  10.9T WDC WD120EMFZ-11A6  9HGK6FFF    0x50014ee2b1a2b666  disk

Що це означає: Ми очікували шість дисків; видно лише п’ять. «Invalid label» може бути насправді через відсутність диска, а не через його пошкодження.

Рішення: Перевірити фізичне підключення, слот шасі, видимість на HBA і журнали. Не перезаписуйте мітки для диска, який ОС навіть не бачить.

Завдання 4: Перевірити журнали ядра на ресети лінків і події зникнення пристроїв

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'sd[a-z]|sas|ata|reset|timeout|I/O error' | tail -n 20
kernel: ata12: hard resetting link
kernel: ata12: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
kernel: sd 12:0:0:0: [sdf] tag#18 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
kernel: sd 12:0:0:0: [sdf] tag#18 CDB: Read(16) 88 00 00 00 00 00 00 00 00 10 00 00 00 08 00 00
kernel: blk_update_request: I/O error, dev sdf, sector 16 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
kernel: sd 12:0:0:0: [sdf] Synchronizing SCSI cache
kernel: sd 12:0:0:0: [sdf] Stopping disk

Що це означає: Тут був пристрій sdf, але читання у тайм-ауті біля початку диска (сектор 16 — це територія міток). Класичний випадок «пошкодженої мітки» через помилку I/O.

Рішення: Сприймайте це як апаратну/шляхову проблему. Пересеґментація, заміна кабелю, спроба іншого порту HBA, перевірка живлення. Якщо це одиночна несправність у RAIDZ2, плануйте заміну диска і дозвольте ZFS відновити дані — після успішного імпорту.

Завдання 5: Перелічити персистентні ідентифікатори пристроїв, щоб уникнути /dev/sdX рулетки

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'WDC_WD120EMFZ|ST8000' | head
lrwxrwxrwx 1 root root  9 Dec 26 10:12 ata-WDC_WD120EMFZ-11A6JA0_9HGK2BBB -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 10:12 ata-WDC_WD120EMFZ-11A6JA0_9HGK3CCC -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 10:12 ata-WDC_WD120EMFZ-11A6JA0_9HGK4DDD -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:12 ata-WDC_WD120EMFZ-11A6JA0_9HGK5EEE -> ../../sdd
lrwxrwxrwx 1 root root  9 Dec 26 10:12 ata-WDC_WD120EMFZ-11A6JA0_9HGK6FFF -> ../../sde

Що це означає: Ці ідентифікатори витримують перезавантаження і перенумерацію пристроїв краще, ніж імена sdX.

Рішення: При імпорті або заміні пристроїв використовуйте ці стабільні ідентифікатори (або еквівалент на вашій ОС). Якщо ваш пул було створено з нестабільними шляхами, подумайте про міграцію конфігурації, коли система знову стане стабільною.

Завдання 6: Переглянути мітки на відомому хорошому диску

cr0x@server:~$ sudo zdb -l /dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_9HGK2BBB | sed -n '1,25p'
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'prod'
    state: 0
    txg: 1984567
    pool_guid: 1692242210959834013
    vdev_guid: 15812007741234567890
    hostid: 1029384756
    hostname: 'fileserver-a'
    top_guid: 7321098765432109876
    guid_sum: 12345678901234567890

Що це означає: Цей диск явно належить пулу prod (pool GUID збігається з переліком при імпорті). Мітки читаються.

Рішення: Використовуйте це як еталон. Тепер перевірте «поганий» диск (якщо він видимий) на читабельність міток і чи належить він тому ж пулу.

Завдання 7: Переглянути мітки на підозрілому диску (якщо він хоча б з’являється)

cr0x@server:~$ sudo zdb -l /dev/sdf
failed to unpack label 0
failed to unpack label 1
failed to unpack label 2
failed to unpack label 3

Що це означає: Всі чотири мітки нечитаються. Це не «один біт». Зазвичай це нечитаємі області, проблема з трансляцією контролера або диск повертає нісенітницю.

Рішення: Якщо це надлишковий vdev (міррор/RAIDZ з достатньою парністю), плануйте заміну sdf. Якщо надлишковість недостатня, ви тепер у зоні відновлення даних і повинні уникати будь-яких записів на цей пристрій.

Завдання 8: Підтвердити, чи диск дійсно виходить з ладу (SMART)

cr0x@server:~$ sudo smartctl -a /dev/sdf | egrep -i 'Reallocated|Pending|Uncorrect|Offline|CRC|SMART overall|Power_On_Hours'
SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always       -       3120
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       128
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       128
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12
Power_On_Hours             0x0032   062   062   000    Old_age   Always       -       31240

Що це означає: Диск виходить з ладу, і лічильники CRC теж присутні (може бути кабель/бекплейн). Нечитаємі мітки узгоджуються з цим.

Рішення: Замініть диск. Також подумайте про заміну кабелю/слоту, бо CRC-помилки часто пов’язані з шляхом. Виправте обидва, інакше ви скоро знову тут опинитеся.

Завдання 9: Спробувати імпорт, обмеживши сканування пристроїв (щоб зменшити плутанину)

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id prod
cannot import 'prod': one or more devices is currently unavailable

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

Рішення: Якщо відсутній пристрій реальний і надлишковість дозволяє, розгляньте можливість імпорту в деградованому режимі з -m (якщо підтримується/доречно), але лише після підтвердження, який vdev відсутній і яка дійсна надлишковість.

Завдання 10: Імпортувати пул (в деградованому стані), якщо дозволяє надлишковість

cr0x@server:~$ sudo zpool import -o readonly=on -m prod
cannot import 'prod': I/O error
        Destroy and re-create the pool from
        a backup source.

Що це означає: Навіть імпорт у деградованому стані неможливий, бо пул потребує даних, які не читаються з залишкових пристроїв, або шлях I/O ненадійний за межі одного диска.

Рішення: Зупиніться і переоцініть: може бути більше одного несправного диска або ваш HBA/бекплейн відкидає пристрої. Поверніться до апаратної перевірки і підтвердіть, що кожен залишковий диск стабільний і читаємий.

Завдання 11: Визначити, який саме GUID vdev відсутній за допомогою zdb (коли перелік імпорту нечіткий)

cr0x@server:~$ sudo zdb -C -e prod | sed -n '1,80p'
MOS Configuration:
        pool_guid: 1692242210959834013
        pool_name: prod
        vdev_children: 1
        vdev_tree:
            type: 'root'
            id: 0
            guid: 7321098765432109876
            children[0]:
                type: 'raidz'
                id: 0
                guid: 882233445566778899
                nparity: 2
                children[0]:
                    type: 'disk'
                    id: 0
                    guid: 15812007741234567890
                    path: '/dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_9HGK2BBB'
                children[1]:
                    type: 'disk'
                    id: 1
                    guid: 15812007749876543210
                    path: '/dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_9HGK3CCC'
                children[2]:
                    type: 'disk'
                    id: 2
                    guid: 15812007740000111111
                    path: '/dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_9HGK1AAA'

Що це означає: ZFS очікує диск із серією 9HGK1AAA, який наразі відсутній/нечитабельний. Тепер у вас є конкретна ціль для фізичної роботи.

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

Завдання 12: Якщо пул імпортовано, перевірте стан перед будь-якими подальшими діями

cr0x@server:~$ sudo zpool status -v prod
  pool: prod
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 0 days 00:42:17 with 0 errors on Sun Dec 22 03:12:19 2025
config:

        NAME                                                   STATE     READ WRITE CKSUM
        prod                                                   DEGRADED     0     0     0
          raidz2-0                                             DEGRADED     0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK1AAA                 UNAVAIL      0     0     0  cannot open
            ata-WDC_WD120EMFZ-11A6JA0_9HGK2BBB                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK3CCC                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK4DDD                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK5EEE                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK6FFF                 ONLINE       0     0     0

errors: No known data errors

Що це означає: Пул працює у деградованому стані; він каже вам, що робити далі.

Рішення: Замініть відсутній пристрій і дочекайтеся resilver. Робіть не scrub одразу «щоб бути впевненим». Спочатку заміна, потім scrub після закінчення resilver, якщо потрібно додатково перевірити цілісність.

Завдання 13: Замінити несправний диск на новий (той самий слот, новий серіал)

cr0x@server:~$ sudo zpool replace prod \
  /dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_9HGK1AAA \
  /dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_NEW9SER1AL

cr0x@server:~$ sudo zpool status prod
  pool: prod
 state: DEGRADED
  scan: resilver in progress since Fri Dec 26 10:44:01 2025
        1.23T scanned at 1.12G/s, 220G issued at 201M/s, 10.9T total
        220G resilvered, 1.94% done, 0 days 15:10:22 to go
config:

        NAME                                                   STATE     READ WRITE CKSUM
        prod                                                   DEGRADED     0     0     0
          raidz2-0                                             DEGRADED     0     0     0
            replacing-0                                        DEGRADED     0     0     0
              ata-WDC_WD120EMFZ-11A6JA0_9HGK1AAA               UNAVAIL      0     0     0  cannot open
              ata-WDC_WD120EMFZ-11A6JA0_NEW9SER1AL             ONLINE       0     0     0  (resilvering)
            ata-WDC_WD120EMFZ-11A6JA0_9HGK2BBB                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK3CCC                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK4DDD                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK5EEE                 ONLINE       0     0     0
            ata-WDC_WD120EMFZ-11A6JA0_9HGK6FFF                 ONLINE       0     0     0

errors: No known data errors

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

Рішення: Моніторьте процес resilver і журнали системи. Якщо бачите тайм-аути, зупиніть героїчні дії і спочатку виправте стабільність апаратури.

Завдання 14: Якщо імпорт скаржиться на «active pool» або власність хоста — перевірте і вирішіть

cr0x@server:~$ sudo zpool import prod
cannot import 'prod': pool may be in use from other system
use '-f' to import anyway

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

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

Завдання 15: Використовуйте rewind (`-F`) лише після вимірювання відкату

cr0x@server:~$ sudo zpool import -F -n prod
Would be able to return pool to state as of TXG 1984501
Would discard approximately 12 seconds of transactions

Що це означає: -n — ваш пас безпеки. Він показує, що буде втрачено при відкаті. Тут це тривіально (секунди), що зазвичай означає крах під час TXG або нечитаємий найновіший uberblock.

Рішення: Якщо вікно відкату прийнятне, продовжуйте з zpool import -F prod. Якщо це години/дні — зупиніться і переосмисліть; можливо, ви імпортуєте неправильні пристрої або маєте глибшу корупцію.

Завдання 16: Після імпорту перевірте поведінку монтування і уникайте неочікуваних записів

cr0x@server:~$ sudo zfs get -o name,property,value,mountpoint,mounted -r mountpoint,mounted prod | head -n 12
NAME                PROPERTY    VALUE    MOUNTPOINT   MOUNTED
prod                mountpoint  /prod    /prod        yes
prod/home           mountpoint  /home    /home        yes
prod/backups        mountpoint  /backups /backups     no
prod/backups        mounted     no       -            -

Що це означає: Не все монтується автоматично, і це може бути навмисно. В режимі відновлення це також може вказувати, що ви імпортували readonly або з альтернативними налаштуваннями mountpoint.

Рішення: Перевірте властивості перед тим, як запускати сервіси. Не дозволяйте застосунку писати в неправильний mountpoint, тому що ви вчора в паніці зробили тимчасовий altroot.

Жарт #2: «У staging працювало» заспокоює, поки ви не згадаєте, що staging — місце, куди дані тихо йдуть у небуття.

Три корпоративні історії з полиць

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

Компанія мала кластер сховища для внутрішніх артефактів — кеші збірок, шари контейнерів, артефакти CI. Не блискуче, але все залежало від цього. Одного ранку після планового обслуговування первинний вузол перезавантажився, і пул не імпортувався. Алерт показував «invalid label» на двох дисках. Інженер на виклику припустив, що диски померли, бо апаратна панель показувала пару помаранчевих лампочок. Проста історія: замінити диски, resilver, жити далі.

Вони поміняли перший диск. Пул все ще не імпортувався. Поміняли другий. Тепер пул не тільки не імпортувався; він також не збирав достатньо метаданих, щоб спробувати відкат. Граф «довіри» виглядав як лижний схил.

Неправильне припущення: помаранчеві лампочки не означали вихід дисків; вони були наслідком проблем з узгодженням лінку у певному бекплейні. Диски були в порядку. Бекплейн періодично презентував неправильні SAS-адреси, і ОС переназивала пристрої між завантаженнями. ZFS бачив «інші диски» з «неправильними мітками», що виглядало як корупція, але насправді це була зміна ідентичності.

Коли вони порівняли виводи zdb -l зі серійними номерами, вони зрозуміли, що «погані» диски були замінені на добрі, які ніколи не були у пулі. ZFS не вперся; він сказав правду. Шлях відновлення був неприємний, але повчальний: повернути оригінальні диски (тепер на стабільному шляху HBA), імпортувати readonly і замінювати по одному правильно.

Після цього вони змінили дві речі. По-перше, правило: ніякої заміни дисків поки не підтверджено ідентичність пристрою і стабільність шляху читання. По-друге, вони перестали покладатися на імена sdX у будь-яких інструкціях. «/dev/sdb» — це настрій, а не ідентифікатор.

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

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

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

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

Оптимізація програла, бо променілась правильність заради швидкості без запобіжних механізмів. Імпорт — не час бути хитрим. ZFS складає узгоджений стан; ваші скрипти не повинні «допомагати», пропускаючи диски, які просто повільно з’являються.

Вони виправили це, зробивши стартову логіку нудною знову: чекати на udev settle, сканувати стабільні шляхи by-id і відмовлятися від автоматичного використання прапорів відкату. Прапори відновлення стали людським рішенням після того, як людина прочитала оцінку відкату.

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

Фінансова організація вела пул ZFS, що підтримував архіви відповідності. Робоче навантаження — «write-once, read-sometimes», з періодичними перевірками scrub. Це та система, яку забувають, поки вона не знадобиться — саме тоді вам не потрібні сюрпризи.

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

Одного дня контролер вийшов з ладу і був замінений по гарантії. Після заміни порядок нумерації пристроїв змінився, і кілька дисків з’явилися з іншими іменами в ОС. Імпорт пулу спочатку не вдався з повідомленням «cannot open» і «invalid label» на, здавалося б, випадкових пристроях.

Інженер на виклику не гадала. Вона витягла останню мапу з тікету, порівняла її з виводами zdb -l на поточному хості і відтворила правильний список пристроїв за шляхами by-id. Пул імпортувався чисто, без відкату і без замовлення нових дисків у паніці.

Це не було героїчно. Це було правильно. Нудні практики не отримують оплесків, але забезпечують спокійний сон.

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

1) Симптом: «invalid label» на диску після перезавантаження

Корінь: Диск присутній, але нечитаємий на початку/кінці (I/O помилки), або ОС замапила інший диск на очікуваний шлях.

Виправлення: Перевірити журнали на тайм-аути I/O, підтвердити серійні номери через lsblk/udevadm, інспектувати мітки за допомогою zdb -l. Замінювати лише після доведення, що це правильний диск і він дійсно вийшов з ладу.

2) Симптом: Імпорт показує «pool may be in use from other system»

Корінь: Пул не був чисто експортований або справді імпортований на іншому хості (спільний JBOD, повторно використані диски, ризик split-brain).

Виправлення: Підтвердити, що інший хост вимкнений або експортував пул. Лише потім використовувати zpool import -f. Якщо пул може бути активний десь ще — зупиніться. Подвійний імпорт — самостійне створення проблем.

3) Симптом: Імпорт вдається лише з відкатом `-F`

Корінь: Найновіший uberblock/TXG нечитаємий (часто через несправний диск або ресет контролера під час запису), або під час спроби імпорту бракувало недавніх пристроїв.

Виправлення: Запустіть zpool import -F -n і прочитайте вікно відкату. Якщо воно маленьке — продовжуйте. Якщо велике — підозрівайте невірні пристрої або ширшу корупцію. Переконайтеся у стабільності апаратури перед повторними спробами імпорту.

4) Симптом: Пул імпортується, але датасети монтуються неправильно або взагалі не монтуються

Корінь: Імпорт з altroot, readonly або зміненим cachefile; або властивості mountpoint були змінені в хаосі.

Виправлення: Перевірте zfs get mountpoint,mounted, підтвердьте zpool get cachefile і уникайте «тимчасових фіксів», що лишаються. Зробіть поведінку монтування явною перед перезапуском сервісів.

5) Симптом: Імпорт завис надовго

Корінь: Один диск таймаутить читання; ZFS чекає на повільне I/O під час виявлення міток/метаданих.

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

6) Симптом: «corrupted data» відразу після того, як хтось «почистив розділи»

Корінь: Інструмент перезаписав області міток (початок/кінець) або змінив зміщення розділів.

Виправлення: Припиніть записувати на диски. Визначте, які диски ще мають цілі мітки через zdb -l. Якщо достатньо міток збережено і надлишковість дозволяє, імпортуйте і замініть. Якщо ні — відновлення з бекапу або спеціалізована реконструкція.

7) Симптом: Після заміни HBA половина дисків показує різні розміри або невідповідність 512/4K

Корінь: Контролер презентує інший логічний розмір секторів або трансляцію (512e vs 4Kn), що плутає припущення щодо ashift і вирівнювання.

Виправлення: Перевірте lsblk -t і логічні/фізичні розміри секторів дисків. По можливості зберігайте узгоджені HBА/прошивки. Не перебудовуйте топологію навмання; спочатку перевірте, потім акуратно змінюйте.

Контрольні списки / покроковий план

Чекліст A: Перш ніж щось чіпати (збір доказів)

Захопіть вивід zpool import і збережіть його в безпечному місці.
Захопіть вивід lsblk -o NAME,SIZE,MODEL,SERIAL,WWN.
Захопіть уривки журналів ядра навколо виявлення дисків і помилок.
Якщо пул видимий, спробуйте zpool import -o readonly=on (і зафіксуйте результат).

Чекліст B: Вирішіть, чи це апарат/шлях чи метадані

Якщо журнали показують тайм-аути/ресети/I/O помилки: спочатку апарат/шлях.
Якщо диски стабільні і читаються, але ZFS каже invalid label: підозрюйте неправильний мапінг пристроїв або перезапис міток.
Використовуйте zdb -l на кількох дисках, щоб підтвердити узгодженість pool GUID.

Чекліст C: Безпечний робочий процес імпорту

Надавайте перевагу імпорту за стабільними шляхами (-d /dev/disk/by-id).
Намагайтеся імпортувати в режимі лише для читання.
Якщо «pool in use», підтвердіть статус іншого хоста перед -f.
Якщо потрібно, оцініть відкат за допомогою -F -n, потім ухваліть рішення.
Після імпорту перевірте zpool status і монтування dataset’ів перед запуском сервісів.

Чекліст D: Відновлення після імпорту (зробити пул здоровим)

Замініть відсутні/несправні пристрої, використовуючи стабільні ідентифікатори.
Моніторьте resilver і журнали; якщо з’являються помилки — зупиніться і виправте шлях I/O.
Після завершення resilver запустіть scrub у контрольований віконний час.
Задокументуйте що сталося: який диск, який слот, який GUID, що показали журнали.

Цитата, яку варто тримати в голові

Парафразована ідея (приписується W. Edwards Deming): Без даних ви — просто ще одна людина з думкою.

Саме тому ви спочатку збираєте виводи, а потім дієте. Відновлення ZFS — не вид спорту для інтуїції.

FAQ

1) Що саме таке «мітка ZFS»?

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

2) Чи означає «пошкоджена мітка» завжди, що диск поганий?

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

3) Чи можу я відновити мітки вручну?

У звичайних операціях ви не «чините мітки», записуючи магічні байти. Правильний підхід: імпортувати, якщо можливо, потім zpool replace несправний/відсутній пристрій і дати ZFS перебудувати надлишковість. Ручний перепис міток — для фахівців і зазвичай після «ми вже щось втратили».

4) Чи небезпечний `zpool import -f`?

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

5) Що насправді робить `zpool import -F`?

Він відкочує пул до попередньої групи транзакцій (TXG), яка здається узгодженою і читаємою. Ви втратите найновіші транзакції після цієї точки. Завжди запускайте з -n спочатку, щоб побачити оцінку відкату.

6) Мій пул імпортується, але в нього деградований стан. Чи варто одразу робити scrub?

Ні. Спочатку замініть відсутні/несправні пристрої. Scrub підвищує навантаження на читання і може довести маргінальні диски до відмови. Спочатку resilver для відновлення надлишковості, потім scrub для впевненості.

7) Чому імпорт іноді зависає?

Тому що ZFS чекає на I/O. Один диск, що таймаутить читання, може затримувати виявлення. Перевірте журнали ядра і SMART; не повторюйте спроби імпорту, поки апарат тане.

8) Як уникнути цього наступного разу?

Використовуйте стабільні ідентифікатори пристроїв, документуйте відповідність диск→слот, регулярно виконуйте scrub, моніторьте ресети лінків/CRC-помилки і тестуйте процедуру відновлення у непанічний час.

9) Якщо одна мітка диска нечитаєма, чи зможе ZFS все одно імпортуватися?

Залежить від топології і надлишковості. Міррори прощають більше. RAIDZ залежить від парності й від того, який диск відсутній. Якщо ZFS не може зібрати дерево vdev або забезпечити вимоги надлишковості, він відмовиться імпортуватися.

10) Чи слід використовувати `zpool import -D` (destroyed pools) у випадках пошкодження міток?

Лише коли у вас є вагомі докази, що пул випадково був знищений/очищений і ви навмисно виконуєте відновлення. Це не інструмент першої лінії для «invalid label» і може ускладнити ситуацію при необережному використанні.

Висновок: що робити наступного разу

Коли ZFS каже «пошкоджені мітки», це не запрошення починати випадкові спроби ремонту. Це прохання зробити те, що найкраще вміють люди з операцій: зменшити невизначеність. Перевірте, що бачить ZFS, підтвердіть ідентичність пристроїв, шукайте проблеми в I/O шляху і інспектуйте мітки за допомогою zdb перед будь-якими змінами.

Практичні наступні кроки:

Стандартизувати використання персистентних імен пристроїв для пулів (by-id/WWN або еквівалент вашої платформи).
Додати крок у рукбуку, що збирає zpool import, lsblk і журнали ядра перед будь-якими замінами.
Моніторити CRC/ресети лінку і розглядати їх як попередження, а не дрібниці.
Вимагати людський дозвіл для імпортів з відкатом (-F) і завжди запускати -n спочатку.
Тримати просту мапу серійний_номер_диска → слот → vdev GUID. Це нудно, тому працює.

Схожі статті

ZFS zpool clear: коли очищення помилок доречне (і коли це дурість) Помилки читання ZFS: коли винен диск, кабель або контролер