Відновлення ZFS: пул не імпортується? Спокійний та відтворюваний шлях виправлення

February 17, 2026 • February 17, 2026 • Читання: 7 хв • Views: 1

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

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

Не потрібні героїчні заходи. Потрібен методичний, нудний, відтворюваний підхід, який залишає докази. Ось шлях виправлення, який я використовую, коли пул не імпортується, а люди починають зарано говорити слова на кшталт «рестворити» та «відновити».

Підхід: зберегти докази, зменшити записи

Коли пул не імпортується, ви опиняєтеся в ситуації судової експертизи, яка маскується під відмову. Ваші цілі:

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

Також: ставтеся до прапорів «force» як до бензопили. Корисний інструмент, але не жонглюйте ним у машинній.

Цитата для стікера в операційному блоці: «Надія — це не стратегія.» — Gene Kranz

Короткий жарт №1: ZFS не імпортується, бо сьогодні відчуває обережність. І я так само, ZFS. І я так само.

Жорстке правило: починайте в режимі тільки для читання, коли це можливо

Якщо ваш перший успішний імпорт буде в режимі read-write, а ви помилилися щодо режиму відмови, ви можете просунути метадані вперед у нову, гіршу реальність. Віддавайте перевагу імпорту тільки для читання для первинного огляду. Пізніше можна змонтувати в RW.

Що означає «не імпортується» насправді

Цей вислів приховує кілька симптомів:

zpool import показує пул, але імпорт завершується помилками I/O.
zpool import взагалі не показує пул.
Імпорт «зависає» (фактично застряг через повторні I/O або очікування повільних пристроїв).
Імпорт працює, але датасети не монтуються або пул одразу переходить у стан suspended.
Пул імпортуєтьcя на неправильному хості (спільний доступ, SAN, катастрофи з JBOD).

Шлях виправлення залежить від того, який саме випадок. Тож ми швидко триажуємо.

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

Це послідовність «припини гортати, почни перевіряти». Мета — швидко знайти вузьке місце: виявлення пристроїв, їхній стан, метадані пулу чи монтування/ключі?

Перший: чи бачить ОС диски стабільно?

Перевірте журнали ядра на предмет скидань/таймаутів.
Підтвердіть стабільну ідентичність пристроїв: by-id, WWN або GPT ID.
Переконайтеся, що HBA/контролер бачить очікувану кількість дисків.

Якщо ОС не бачить диски чисто, ZFS не є першопричиною. ZFS — просто перший чесний свідок.

Другий: чи бачить `zpool import` пул і що воно каже?

Якщо пул зʼявляється: уважно прочитайте статус, особливо “UNAVAIL,” “was /dev/…,” “insufficient replicas,” і last TXG.
Якщо не зʼявляється: проскануйте шляхи вручну, перевірте проблему з cachefile і розгляньте пошкодження міток.

Третій: імпортуйте в найменш ризиковому режимі

Спробуйте спочатку імпорт тільки для читання (-o readonly=on).
Тільки потім розглядайте прапори rewind/rollback (-F з або без -X), і лише після того, як зрозумієте, що готові пожертвувати.
Якщо є шифрування, відокремте «імпорт пулу» від «монтування датасету»: ключі можуть блокувати монтування навіть коли пул імпортовано.

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

ZFS зберігає кілька міток на пристрої. Кожний диск зазвичай має мітки біля початку та в кінці, тому часткове пошкодження мітки може все ще бути відновленим.
Імпорти пулів базуються на транзакціях. ZFS просувається через TXG (transaction groups). Операції rewind обирають старіший консистентний TXG.
«Uberblocks» — це крихти слідів. ZFS записує кілька uberblock; логіка імпорту вибирає найкращий валідний між пристроями.
OpenZFS — це жива лінія розвитку. ZFS походить від Sun Microsystems, а далі продовжувався як OpenZFS на illumos, FreeBSD та Linux, зі feature flags для сумісності.
Feature flags — не косметика. Пул з новішими feature flags може не імпортуватися на старішій системі, навіть якщо диски здорові.
ZFS дуже старається уберегти від split-brain. Поведінка hostid і multihost існує, бо імпорт одного і того ж пулу на двох машинах може швидко його пошкодити.
Самовідновлення потребує надмірності. Контрольні суми виявляють ушкодження, але без mirror/RAIDZ паритету ZFS не завжди може відновити дані автоматично.
Імпорт може бути повільним за задумом. При великій кількості дисків або нестабільному обладнанні ZFS може перевіряти мітки та повторювати I/O; це може виглядати як зависання, поки воно працює ретельно.

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

Нижче — практичні завдання, які я виконую приблизно в такому порядку. Кожне містить, на що звертати увагу і яке рішення приймати. Запускайте як root або через sudo. Зберігайте вивід у файл, якщо ви на дзвінку з іншими командами.

Завдання 1: Зафіксуйте очевидне: що ZFS думає зараз?

cr0x@server:~$ zpool status -v
no pools available

Що це означає: Нічого не імпортовано. Це ще не діагноз; це відправна точка.

Рішення: Переходимо до виявлення: чи бачить система пул на диску?

Завдання 2: Перелічіть імпортовані пулі (і не ігноруйте текст)

cr0x@server:~$ zpool import
   pool: tank
     id: 1234567890123456789
  state: UNAVAIL
 status: One or more devices are unavailable.
 action: The pool cannot be imported. Attach the missing devices and try again.
   see: zpool(8)
 config:

        tank        UNAVAIL  insufficient replicas
          raidz1-0  UNAVAIL  insufficient replicas
            sda     ONLINE
            sdb     ONLINE
            sdc     UNAVAIL  cannot open
            sdd     ONLINE

Що це означає: ZFS бачить метадані пулу і точно каже, чому не імпортує: insufficient replicas через брак члена vdev (RAIDZ1 витримує одну втрату; тут може бути втрата більше ніж одного, або відсутній диск фактично присутній, але недоступний).

Рішення: Припиніть пробувати випадкові прапори імпорту. Спочатку виправте видимість пристрою: зʼясуйте, чому sdc не відкривається.

Завдання 3: Підтвердіть ідентичність пристрою (не довіряйте /dev/sdX)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|wwn-' | head
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123457 -> ../../sdb
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123458 -> ../../sdd

Що це означає: Очікуваний запис by-id відсутній або вказує не туди, куди треба. Це часто проблема з кабелями/HBA, померлим диском або зміною режиму/простору імен диска.

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

Завдання 4: Триаж журналів ядра на помилки I/O та скидання

cr0x@server:~$ dmesg -T | egrep -i 'error|reset|timeout|sas|scsi|nvme' | tail -n 20
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] Sense Key : Hardware Error [current]
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] Add. Sense: Internal target failure
[Mon Feb  4 09:08:13 2026] mpt3sas_cm0: log_info(0x31120405): originator(PL), code(0x12), sub_code(0x0405)
[Mon Feb  4 09:08:14 2026] scsi 6:0:12:0: rejecting I/O to offline device

Що це означає: Диск або шлях відмовляє на транспортному рівні. ZFS правий відмовлятися імпортувати при недостатній надмірності.

Рішення: Виправляйте обладнання спершу: пересадіть, замініть або перемістіть диск/шлях. Якщо це dual-path SAN/JBOD — перевірте конфігурацію multipath.

Завдання 5: Переконайтеся, що у вас сумісна версія OpenZFS/feature

cr0x@server:~$ zpool upgrade -v | head -n 12
This system supports ZFS pool feature flags.

The following features are supported:

FEAT DESCRIPTION
async_destroy                        Destroy filesystems asynchronously.
bookmarks                           ZFS bookmarks.
embedded_data                       Blocks which compress very well use even less space.

Що це означає: Ця хоста загалом підтримує feature flags, але це не підтверджує точні прапори пулу.

Рішення: Якщо пул останнім часом імпортувався на новішій системі, можливо, потрібно імпортувати там або оновити цю систему. Невідповідності часто проявляються як «unsupported feature» при імпорті.

Завдання 6: Отримайте детальний вивід скану імпорту (історія пулу)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank
cannot import 'tank': one or more devices is currently unavailable

Що це означає: Навіть при скануванні стабільних шляхів і уникненні старого cachefile, vdev відсутній.

Рішення: Якщо надмірності достатньо, ви можете імпортувати в degraded. Якщо ні — припиніть і відновіть відсутні диски/шляхи.

Завдання 7: Подивіться, чи просто ZFS чекає (триаж «зависання» імпорту)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank

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

Рішення: В іншому терміналі підтвердіть, чи активний процес і чи пристрої таймаутять.

cr0x@server:~$ ps -eo pid,etime,cmd | egrep 'zpool import|PID'
  PID     ELAPSED CMD
 8421       02:14 zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank

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

Завдання 8: Перевірте активні I/O і визначте повільний пристрій

cr0x@server:~$ iostat -x 1 5
Linux 6.6.0 (server)  02/04/2026  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.02    0.00    2.31   35.44    0.00   61.23

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
sda              1.0      32.0     0.0    0.0   12.0    32.0       0.0      0.0     0.0    0.01    2.0
sdb              1.0      32.0     0.0    0.0   10.0    32.0       0.0      0.0     0.0    0.01    2.0
sdc              0.0       0.0     0.0    0.0    0.0     0.0       0.0      0.0     0.0    0.00    0.0
sdd              1.0      32.0     0.0    0.0   11.0    32.0       0.0      0.0     0.0    0.01    2.0

Що це означає: Великий iowait з одним пристроєм, що нічого не показує, може означати, що він не відповідає або ядро відключило його. Або один пристрій на 100% util з великим await тягне імпорт.

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

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

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N tank
cannot import 'tank': one or more devices is currently unavailable

Що це означає: Read-only не обходить відсутні пристрої. Він просто знижує ризик, коли імпорт можливий.

Рішення: Якщо надмірність існує (mirror/RAIDZ з терпимою втратою), використайте degraded import. Якщо ні — зупиніться і відновіть відсутні диски/шляхи.

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

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N -f -o failmode=continue tank
cannot import 'tank': insufficient replicas

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

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

Завдання 11: Якщо пул імпортується, але датасети не монтуються — перевірте шифрування і налаштування mount

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f vault
cr0x@server:~$ zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
vault           1.2T   800G    96K  /vault
vault/secure     0B     800G    96K  /vault/secure

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

Рішення: Перевірте стан ключів, потім завантажте ключі і змонтуйте цілеспрямовано.

cr0x@server:~$ zfs get -H -o name,property,value keystatus vault/secure
vault/secure	keystatus	unavailable

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

cr0x@server:~$ zfs load-key -r vault/secure
Enter passphrase for 'vault/secure':
cr0x@server:~$ zfs mount -a
cr0x@server:~$ mount | grep vault
vault on /vault type zfs (ro,relatime,xattr,noacl)
vault/secure on /vault/secure type zfs (rw,relatime,xattr,noacl)

Завдання 12: Якщо імпорт скаржиться на «active pool» або неправильний хост, перевірте hostid і ситуацію multihost

cr0x@server:~$ zpool import
   pool: prod
     id: 9876543210987654321
  state: ONLINE
 status: The pool is currently imported by another system.
 action: The pool must be exported from the other system, then imported.
   see: zpool(8)
 config:

        prod        ONLINE
          mirror-0  ONLINE
            wwn-0x5000c500a1b2c3d4  ONLINE
            wwn-0x5000c500a1b2c3d5  ONLINE

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

Рішення: Підтвердіть, що інший хост справді вимкнений або виконав export. Якщо ви не на 100% впевнені — зупиніться. Корупція в мультихостовому режимі трапляється швидко й боляче.

Завдання 13: Якщо мусите форсувати імпорт — робіть це спочатку в режимі тільки для читання

cr0x@server:~$ zpool import -f -o readonly=on -o cachefile=none -N prod
cr0x@server:~$ zpool status -x
pool 'prod' is healthy

Що це означає: Ви отримали пул безпечно (read-only, без монтувань). Це режим для інспекції.

Рішення: Перевірте дані і стан пристроїв перед переключенням у read-write. Якщо це питання володіння — сплануйте чистий sequence export/import.

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

cr0x@server:~$ zpool status -v prod
  pool: prod
 state: SUSPENDED
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
config:

        NAME                        STATE     READ WRITE CKSUM
        prod                        SUSPENDED     0     0     0
          mirror-0                  DEGRADED      0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE        0     0     0
            wwn-0x5000c500a1b2c3d5  FAULTED       0    12     0  too many errors

errors: No known data errors

Що це означає: ZFS призупинив I/O, щоб захистити консистентність. Зазвичай це пристрій, що пішов в сторону під час операції.

Рішення: Виправте/змініть несправний пристрій спершу. Clearing без виправлення — це просити ZFS відновити запис у вогонь.

Завдання 15: Після виправлення обладнання очистіть помилки і навмисно виконайте відновлення

cr0x@server:~$ zpool clear prod
cr0x@server:~$ zpool status 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: Attach the missing device and online it using 'zpool online'.
config:

        NAME                        STATE     READ WRITE CKSUM
        prod                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  UNAVAIL      0     0     0  cannot open

Що це означає: Пул працює на залишкових репліках. Потрібно приєднати/замінити відсутню сторону.

Рішення: Замініть несправний диск і дочекайтеся resilver. Не лишайте його degraded «трохи» — так «трохи» стане «знову дзвінок у пейджер».

Завдання 16: Визначте останні TXG і розгляньте rewind лише при ймовірній корупції

cr0x@server:~$ zpool import -F -n -d /dev/disk/by-id tank
Would be able to return pool to state as of Tue Feb  3 18:22:41 2026.
Would discard 2.14G of transactions.

Що це означає: Доступний dry-run rewind. Він повернув би пул до старішого стану і відкинув частину записів. Це може бути прийнятним, якщо альтернатива — «немає пулу». Також може бути неприйнятним, якщо ті записи критичні.

Рішення: Зупиніться і узгодьте з відповідальними. Якщо погоджуєтеся, проведіть перший успішний імпорт read-only, перевірте датасети, а вже потім вирішуйте щодо RW.

Завдання 17: Виконайте rewind import обережно (лише якщо погодилися відкинути TXG)

cr0x@server:~$ zpool import -F -o readonly=on -o cachefile=none -N -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
status: Pool was previously in use from another system.
action: Export the pool from the other system, then import it.
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     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Що це означає: Пул знову доступний (у режимі інспекції read-only). Попередження «previously in use» часто зʼявляється після краху або міграції; воно не завжди означає реальний мультихостовий конфлікт, але ставтеся серйозно.

Рішення: Перевірте дані, export/import коректно, а потім імпортуйте в RW. Якщо у вас справді мультихостова архітектура — виправте її.

Завдання 18: Після імпорту монтуйте цілеспрямовано і перевірте

cr0x@server:~$ zfs mount -a
cr0x@server:~$ zfs list -o name,used,avail,mountpoint | head
NAME               USED  AVAIL  MOUNTPOINT
tank               128K  10.9T  /tank
tank/home          2.1T  10.9T  /tank/home
tank/vm            6.4T  10.9T  /tank/vm

Що це означає: Датасети змонтовані, mountpoint-и мають сенс, і ви можете переходити до перевірок на рівні додатків.

Рішення: Якщо mountpoint-и неправильні (наприклад, legacy проти керованих ZFS), зупиніться і виправте властивості перед запуском сервісів.

Режими відмов, які реально можна виправити

1) Пул в порядку; ОС не бачить диски (або бачить інакше)

Більшість інцидентів «ZFS не імпортується» насправді — «змінився шар зберігання». Часті тригери:

Оновлення прошивки HBA змінило порядок нумерації дисків.
СAS expanders хитали під навантаженням.
NVMe простори імен змінилися після запуску утиліти від вендора.
Multipath некоректно налаштовано і подається по два вузли пристрою на LUN.

Виправлення: Спершу стабілізуйте шар пристроїв. Використовуйте by-id шляхи; підтвердіть наявність усіх очікуваних WWN; видаліть застарілі multipath вузли; замініть кабелі/трансивери.

2) Плутанина з cachefile і застарілі шляхи пристроїв

На деяких системах ZFS використовує cachefile, щоб запам’ятати шляхи vdev. Якщо cachefile вказує на старі /dev/sdX імена, імпорт може падати, хоча диски існують.

Виправлення: Використовуйте -o cachefile=none і явно скануйте -d /dev/disk/by-id. Після чистого імпорту встановіть адекватний шлях cachefile для ОС або дозвольте сервісу керувати ним.

3) Невідповідність feature flag / версії

Якщо пул оновили (увімкнули feature flags) на одному хості, старі хости можуть відмовитись його імпортувати. Це виглядає як помилка імпорту, а не як відмова диска.

Виправлення: Імпортуйте на системі з сумісною підтримкою OpenZFS feature. Якщо треба переміщувати пули між хостами — керуйте версіями ZFS так само ретельно, як версіями баз даних: свідомо.

4) Корупція в останніх TXG після краху (територія rewind)

Несподівана втрата електроживлення плюс write cache може залишити останній TXG неконсистентним. ZFS зазвичай виявляє і уникає неконсистентних uberblocks, але іноді треба відкотитися.

Виправлення: Використовуйте zpool import -F -n, щоб побачити вартість відкату. Продовжуйте тільки якщо приймаєте відкидання останніх транзакцій. Перший імпорт робіть read-only.

5) Пул призупинений через помилки I/O

Це ZFS робить правильно: зупиняє I/O, щоб захистити консистентність. Людям це не подобається, бо це голосно, але це кращий результат, ніж тиха корупція.

Виправлення: Визначте і замініть/відновіть несправний шлях пристрою. Потім zpool clear і resilver.

6) Попередження «Imported elsewhere» (реальний мультихост або застарілий стан)

Іноді інший хост дійсно працює з пулом. Іноді він впав і лишив сліди. У будь-якому випадку імпорт на двох хостах — це як звести відновлення у криміналістику.

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

Короткий жарт №2: Форсувати імпорт на спільному сховищі, не перевіривши інший хост — як злити у main без тестів: технічно можливо, емоційно дорого.

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

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

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

Після перезавантаження пул ZFS не імпортувався. На чергуванні побачили помилки cannot open для кількох пристроїв і одразу запідозрили відмову дисків. Було відправлено заявку в дата-центр на вилучення дисків. Це дорога рефлексія: заміни дисків легко зробити неправильно, і кожне витягування — шанс створити другий простій.

Через 30 хвилин хтось нарешті виконав zpool import -d /dev/disk/by-id -o cachefile=none і побачив метадані пулу цілком цілими. Проблема була в тому, що cachefile системи посилався на старі /dev/sdX шляхи, а нова нумерація HBA не співпала. Ніхто не перевірив стабільні ідентифікатори.

Виправлення було нудне: імпорт по by-id, оновлення поведінки cachefile і додавання до чекліста кроку, який перевіряє наявність усіх WWN після зміни контролера. Постмортем виявив справжню проблему: неправильне припущення було не про ZFS, а про ідентичність.

Міні-історія №2: Оптимізація, яка відплатилася

Команда хотіла швидші синхронні записи для логінгового конвеєра. Додали швидкі споживчі SSD як SLOG, налаштували агресивно та раділи, коли бенчмарки подвоїлися. Потім сталося апаратне: подача електрики і brownout, який не повністю вимкнув стійку, але заплутав кілька пристроїв.

Після перезавантаження імпорт пулу іноді вдався, іноді зависав. Логи показували інтермітентні скидання і «Internal target failure» на одному з SSD. Оскільки SLOG стояв на ненадійному споживчому пристрої без захисту від втрати живлення, система довго намагалася звʼязатися з ним під час імпорту. Це не була єдина проблема, але найгучніша.

Першою «лікуванням» було форсувати імпорт усіма можливими прапорами. Це іноді допомагало, але стабільності не давало. ZFS робив, що міг; обладнання — що хотіло.

Реальне відновлення: фізично видалити несправний лог-пристрій (або замінити на відомо-надійний пристрій з PLP), потім імпортувати read-only, замінити погані частини, а потім знову додати SLOG з правильними критеріями вибору. «Оптимізація» перетворилася на плату за доступність.

Урок: якщо ви оптимізуєте межі надійності (sync writes, intent logs, write caches), ви успадковуєте їхні режими відмов. Якщо ваш бізнес цінує ці записи, ваше обладнання має це забезпечити.

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

В одному підприємстві була політика: в кожний шасі зберігання вкладали ламінований лист в дверцята. Він містив відображення слот → WWN → членство в pool/vdev. Це виглядало як артефакт 90-х, і всі сміялися, поки це не знадобилося.

Пул перестав імпортуватись після того, як підрядник з обслуговування «прибрав кабелі». Половина дисків була присутня, половина — невидима. Підрядник клявся, що нічого не чіпав. Логи ОС казали інше.

Тому що команда мала відображення слот→WWN, вони швидко визначили фізичні слоти для відсутніх WWN і відслідкували проблему до одного кабелю експандера, сяючого не повністю в гнізді. Ніяких гадань. Жодного «спробуй поміняти sdc і sdd». Жодного випадкового видалення невірного диска з єдиної діючої сторони mirror.

Пул імпортнувся degraded, потім повністю після фіксу кабелю. Resilver завершився вночі. Політика була нудною. Але вона також була різницею між двогодинним інцидентом і багатоденною відновою.

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

1) Симптом: `zpool import` нічого не показує

Корінь проблеми: Пристрої не виявлені, неправильний шлях сканування або мітки нечитабельні через апаратні/драйверні проблеми. Іноді пул існує, але за multipath вузлами, які ви не скануєте.

Виправлення: Скануйте явні каталоги (-d /dev/disk/by-id), перевірте dmesg на помилки виявлення пристроїв і підтвердіть наявність очікуваних WWN. Якщо це SAN — переконайтеся, що multipath подає один стабільний пристрій на LUN.

2) Симптом: Імпорт падає з «insufficient replicas»

Корінь проблеми: Занадто багато відсутніх пристроїв у vdev. Mirrors потребують однієї сторони; RAIDZ потребує достатньої кількості учасників для відновлення паритету; якщо нижче порогу, ZFS не може зібрати vdev.

Виправлення: Відновіть відсутні пристрої (кабель/HBA/шлях), замініть несправні диски або відновіть з бекапу. Не очікуйте, що -f подолає закони фізики.

3) Симптом: Імпорт зависає нескінченно

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

Виправлення: Визначте повільний/несправний пристрій через журнали ядра і iostat. Видаліть/змініть винуватця. Потім повторіть імпорт, бажано спочатку read-only.

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

Корінь проблеми: Імпорт з -N, властивості mountpoint, legacy mounts або незавантажені ключі шифрування.

Виправлення: Перевірте zfs get mountpoint,canmount,keystatus. Завантажте ключі за потреби. Змонтуйте явно через zfs mount -a або поштучно.

5) Симптом: Пул одразу стає SUSPENDED

Корінь проблеми: ZFS виявив повторні помилки I/O і призупинився для захисту пулу. Часто пристрій фолтить під навантаженням запису.

Виправлення: Замініть/виправте шлях пристрою. Потім очистіть помилки і виконайте resilver. Не продовжуйте лише очищати без вирішення обладнання.

6) Симптом: «The pool is currently imported by another system»

Корінь проблеми: Або справді імпортовано деінде, або система думає, що так (застарілий стан після краху). У спільних середовищах це ключове попередження.

Виправлення: Підтвердіть ексклюзивність: переконайтеся, що інші хости не бачать дисків, потім імпортуйте спочатку в read-only. Впровадьте multihost і операційні контролі, якщо існують спільні шафи.

7) Симптом: Помилка імпорту згадує unsupported features

Корінь проблеми: Пул створено або оновлено з feature flags, які не підтримує ця реалізація ZFS/версія.

Виправлення: Імпортуйте на новішому сумісному хості. Узгодьте версії ZFS у флоті. Не «оновлюйте pool features» необережно в мішаних середовищах.

8) Симптом: Після форсованого імпорту дані виглядають «старішими, ніж очікувалося»

Корінь проблеми: Відкат/rewind відкинув останні TXG, або додатки припускали інші sync semantics.

Виправлення: Розглядайте rewind як свідому втрату даних. Чітко комунікуйте. Перевірте цілісність на рівні додатків; відновіть логи додатків, якщо доступні.

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

Фаза 0: Зафіксуйте сцену (5–10 хвилин)

Зупиніть будь-яку автоматизацію, що може продовжувати повторювані імпорти або монтування датасетів.
Зафіксуйте: dmesg -T, journalctl -k (якщо доступно), zpool import та вивід апаратної інвентаризації.
Підтвердьте, чи це спільне сховище. Якщо так — переконайтеся, що тільки один хост має доступ до дисків.

Фаза 1: Істина шару пристроїв

Перелічіть стабільні ідентифікатори: ls -l /dev/disk/by-id.
Порівняйте очікувані WWN з наявними (з вашого інвентарю, міток або останнього відомого zpool status).
Перевірте журнали ядра на скидання/таймаути для відсутніх пристроїв.
Виправте кабелі/HBA/диски, поки всі очікувані пристрої не стануть присутніми та стабільними.

Фаза 2: Недеструктивне виявлення ZFS і спроба імпорту

Скануйте явно: zpool import -d /dev/disk/by-id.
Якщо пул зʼявився — зафіксуйте стан, відсутні vdev і будь-які підказки «last TXG».
Спробуйте безпечний імпорт: zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N POOL.
Якщо імпорт відбувся — перегляньте zpool status -v і zfs list перед монтуванням або запуском сервісів.

Фаза 3: Контрольований ризик (лише коли необхідно)

Якщо імпорт не вдається через підозру на недавню корупцію — спробуйте dry-run rewind: zpool import -F -n POOL.
Вирішіть, чи готові відкинути показані транзакції. Розглядайте це як втрату даних.
Якщо йти далі — імпортуйте з rewind у режимі read-only спочатку: zpool import -F -o readonly=on -N POOL.
Перевірте дані, потім export і звичайний import у read-write, якщо це доречно.

Фаза 4: Після імпорту — зробіть систему знову стабільною

Замініть несправні пристрої і дочекайтеся resilver.
Запустіть scrub, коли система стабільна і витрати продуктивності прийнятні.
Документуйте корінь проблеми. Оновіть runbook-и та мапи інвентарю.

Чого уникати (повторювані помилки)

Не запускайте деструктивні команди (наприклад, перерозподіл, форматування або «ініціалізація» дисків) на пристроях, які ви не ідентифікували по WWN/серійному номеру.
Не оновлюйте pool features під час відновлення. Час відновлення — не час для фіч.
Не імпортуйте у read-write спочатку, коли ви не впевнені. Ви дебагуєте; мінімізуйте побічні ефекти.
Не ігноруйте логи обладнання. Вони зазвичай говорять правду, якої ви не хочете чути.

Питання та відповіді

1) Чи слід відразу пробувати `zpool import -f`?

Ні. Спочатку визначте, чи пул дійсно імпортовано деінде, і чи відсутні пристрої. Force import призначений для конфліктів володіння, а не для відсутніх дисків.

2) Що дає `-o cachefile=none`?

Це забороняє ZFS довіряти потенційно застарілим кешованим шляхам і змушує виконати свіжий скан зазначених пристроїв. Це дешевий спосіб виключити проблему «старі /dev/sdX імена».

3) Чому ви постійно кажете «скануйте by-id»?

/dev/sdX імена призначаються під час завантаження і можуть змінюватися при зміні контролерів, прошивки або часових характеристик дисків. Іменування by-id і WWN — це як зберігати здоровий глузд у продакшні.

4) Якщо я можу імпортувати read-only, чи можу я просто скопіювати дані та перебудувати?

Часто так, і це відмінний крок, коли ви підозрюєте прогресуюче апаратне погіршення. Імпорт read-only зменшує шанс погіршити метадані під час вилучення даних.

5) Коли доречний rewind (`zpool import -F`)?

Коли ви впевнені, що останні TXG неконсистентні (крах під час запису, write cache lies, раптова втрата живлення) і звичайний імпорт не вдається. Завжди робіть -n спочатку, щоб побачити вартість.

6) Чи може ZFS відновити silent corruption без надмірності?

ZFS може виявити корупцію за контрольними сумами. Відновлення вимагає надмірності (mirror/RAIDZ або копії) або зовнішнього джерела довіри (бекуп). Виявлення без відновлення все ще корисне; воно каже, чому даним не можна довіряти.

7) Чому імпорт так довго триває на великих пулах?

Імпорт може перевіряти мітки на багатьох дисках і повторювати I/O, коли пристрої повільно відповідають. Якщо один диск флапає, час імпорту може зрости, бо ядро продовжує допомагати.

8) Що якщо пул імпортується, але мої додатки все ще падають?

Відокремлюйте стан сховища від коректності додатків. Перевірте mountpoint-и датасетів, ключі шифрування і те, чи сервіси очікують конкретних шляхів/дозволів. Потім перевіряйте консистентність на рівні додатка.

9) Чи безпечно одразу запускати scrub після відновлення?

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

10) Як запобігти проблемам «pool imported elsewhere»?

Архітектурно: не демонструйте ті самі диски на кілька хостів без розробленої, протестованої мультихостової стратегії. Операційно: впровадьте fencing і використовуйте стабільні практики ідентифікації хостів.

Висновок: наступні кроки для зменшення повторень інцидентів

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

Практичні наступні кроки, які я би призначив після інциденту:

Стандартизувати vdev шляхи по by-id/WWN для всіх пулів. Виправити поодинокі legacy пули до того, як вони стануть простою.
Додати передобслуговувальний чек, що фіксує zpool status, інвентар WWN і версії прошивки контролерів.
Переглянути write cache, захист від втрати живлення і будь-які «оптимізації продуктивності», які змінюють моделі відмов.
Репетирувати відновлення в лабораторії: імпорт з відсутніми пристроями, тест dry-run rewind, відпрацювати роботу з ключами шифрування.
Зробити бекапи нудними і перевіреними. ZFS — стійка, але не магічна.

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