Proxmox ZFS «не вдається імпортувати пул»: причини, перевірки та варіанти відновлення

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

Proxmox тут не творить нічого містичного. Це Debian-хост із інструментами ZFS. Якщо пул не імпортується,
Proxmox не може змонтувати datasets, не може надати ZVOL, і визначення сховища в GUI перетворюється на сумний неактивний ярлик.

Процес імпорту — це те, що ZFS читає мітки з vdev-ів, відтворює стан пулу з останнього узгодженого transaction group (TXG),
і перевіряє, чи безпечно відкрити пул з ідентичністю поточного хоста та шляхами до пристроїв.
Коли імпорт не вдається, це майже завжди одна з п’яти категорій:

• Проблеми з видимістю пристроїв: диски відсутні (або нестабільні), неправильні шляхи by-id, HBA/прошивка, конфлікти multipath.
• Перевірки цілісності метаданих: multihost/hostid mismatch, застарілі імпорти, пул вважає, що він ще активний деінде.
• Корупція або неповні записи: некоректні вимкнення, bad blocks, відмови пристрою, через які нечитабельні мітки/uberblocks.
• Невідповідність фіч/властивостей: старі userspace інструменти проти pool feature flags, ключі шифрування не завантажені, неподтримувані опції.
• Порядок завантаження та імпорту в Proxmox: initramfs, служба zfs-import, устарілий cachefile, race condition під час завантаження.

Завдання — визначити, у який «бакет» ви потрапили, використовуючи докази, а потім вибрати найменш ризикований метод імпорту,
який поверне сервіс. Почніть з read-only імпорту, уникайте «force», якщо не можете пояснити іншому інженеру, чому це безпечно,
і не «пробуйте усе підряд» на єдиній копії ваших даних.

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

0. Зупиніть кровотечу: стабілізація

• Якщо це спільне сховище або потенційно видиме для кількох хостів (SAS shelf, iSCSI LUNs, FC), переконайтеся, що лише один хост має доступ. Від’єднайте кабелі або відключіть таргети, якщо треба.
• Заморозьте автоматизацію: зупиніть cron-джоби, бекапи та все, що може продовжувати опитувати пристрої.
• Якщо підозрюєте відмову дисків, уникайте циклів перезавантажень. Кожен ребут — ще одна гра в кубики.

1. Перша перевірка: чи присутні та стабільні vdev-и?

Більшість випадків «не вдається імпортувати» — це не «ZFS зламався». Це «шлях до диска змінився», «HBA неохоче працює» або «multipath брешe».
Підтвердіть видимість пристроїв і переконайтеся, що це ті самі диски, які ви очікуєте.

• Запустіть zpool import і прочитайте точне повідомлення про помилку.
• Перевірте ls -l /dev/disk/by-id на предмет очікуваних WWN.
• Перегляньте dmesg -T на предмет resets, timeouts, «I/O error», «offline device».

2. Друга перевірка: чи ZFS відмовляє з міркувань безпеки (hostid/multihost/stale state)?

Якщо ZFS вважає, що пул активний на іншій системі, він відмовить або вимагатиме явного override. Це добре; так запобігають split-brain записам.
Шукайте «pool may be in use from another system» і перевірте hostid.

3. Третя перевірка: чи можна імпортувати у режимі лише для читання і оглянути?

Якщо пул видно, зробіть read-only import. Це найближче до «безпечного режиму», який має ZFS.
Якщо read-only імпорт не вдається, ймовірно, маємо відсутні пристрої, серйозну корупцію, неподтримувані фічі або проблеми з ключами шифрування.

Якщо нічого іншого не зробите: зберіть виходи для zpool import -D, zdb -l на кожному пристрої і journalctl -u zfs-import-cache -u zfs-import-scan.
Ці три зазвичай вказують, куди рухатися далі.

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

1. Пули ZFS самоописувані: конфігурація зберігається на кожному vdev label, а не в одному крихкому файлі.
2. Імпорт — це процес консенсусу: ZFS обирає найновіший узгоджений TXG між пристроями; це не просто «монтуємо і сподіваємося».
3. Hostid існує, щоб запобігти split brain: ZFS може записувати останній хост, що імпортував пул, і блокувати небезпечні імпорти коли multihost=on.
4. Feature flags замінили номера версій: сучасні пули рекламують фічі; старі інструменти можуть відмовити в імпорті, якщо не можуть їх зрозуміти.
5. ZFS віддає перевагу стабільним ідентифікаторам пристроїв: /dev/sdX — це суб’єктивно, не факт. /dev/disk/by-id — дорослий вибір.
6. Cachefile — це оптимізація: він пришвидшує імпорт, але застарілий cachefile може ввести в оману під час завантаження після змін в обладнанні.
7. OpenZFS відрізняється від Solaris ZFS: Proxmox використовує OpenZFS на Linux, з власними тонкощами інтеграції завантаження і порядку служб.
8. Scrub — це не бекап: scrubs знаходять і виправляють мовчазну корупцію (якщо є надлишковість), але вони не захистять від «rm -rf» або втрати ключів шифрування.

Кореневі причини: звичні підозрювані з ознаками

1) Диски відсутні, перейменовані або періодично відключаються

Ознаки: cannot import 'pool': no such pool available, або one or more devices is currently unavailable.
В Proxmox це часто після перезавантаження, заміни HBA, оновлення прошивки, переміщення шельфів або «ми впорядкували кабелі».

Реальність: мітки ZFS є на дисках, але Linux може їх не показувати стабільно, або udev-імена змінилися,
або multipath створює дублікати вузлів. Пул може бути імпортований з -d /dev/disk/by-id або після виправлення виявлення пристроїв.

2) Пул виглядає «використовується» на іншій системі (hostid / multihost / stale import)

Ознаки: pool may be in use from another system. Це звично після клонування завантажувальних дисків, відновлення образів Proxmox,
або імпорту пулу, який останнім використався на іншому вузлі.

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

3) Ключ шифрування недоступний (native ZFS encryption)

Ознаки: імпорт проходить, але datasets не монтуються, або імпорт не вдається з помилками, пов’язаними з ключами.
Proxmox може показувати сховище як присутнє, але непридатне.

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

4) Непідтримувані feature flags або невідповідність версій

Ознаки: імпорт відмовляє з повідомленнями про unsupported features, або «pool uses the following feature(s) not supported by this system.»

Реальність: ви оновили пул на новішому OpenZFS, а потім намагаєтеся імпортувати на старому вузлі Proxmox або у rescue-середовищі.
Зазвичай рішення — завантажити сучасне середовище з відповідним OpenZFS, а не «понижувати пул» (його не можна понизити).

5) Пошкодження метаданих / відмова пристрою / нечитабельні мітки

Ознаки: I/O помилки під час імпорту, cannot open на конкретних vdev-ах, bad label, повторні спроби або пул видно в zpool import, але не імпортується.

Реальність: один або більше пристроїв не можуть прочитати критичні метадані. Надлишковість допомагає. Без надлишковості — ви в зоні відновлення: спробуйте read-only, імпорт з відсутніми пристроями,
і будьте готові швидко копіювати дані.

6) Гонки при завантаженні та застарілі cachefile

Ознаки: пул імпортується вручну, але не при завантаженні; сховище Proxmox «втрачене» після ребуту, поки ви не виконаєте zpool import.

Реальність: служби імпорту ZFS стартували раніше, ніж готові пристрої, або cachefile вказує на старі шляхи. Пул у порядку; порядок завантаження — ні.

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

Це ті завдання, які я реально виконую під час інцидентів. Кожне містить: команду, реалістичний фрагмент виходу, що це означає, і рішення, яке ви приймаєте.
Виконуйте їх від root (або з sudo) на вузлі Proxmox або в rescue-shell з встановленими ZFS-інструментами.

Task 1: Подивіться, що ZFS вважає імпортованим

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 status: The pool was last accessed by another system.
 action: The pool can be imported using its name or numeric identifier and the '-f' flag.
 config:

        rpool       ONLINE
          sda3      ONLINE

Що це означає: ZFS бачить пул і його vdev(и). Блокером є «last accessed by another system».

Рішення: Перед використанням -f доведіть, що лише цей хост може писати на ці диски (особливо якщо це shared storage). Якщо це локальні диски на одному хості — продовжуйте з forced import.

Task 2: Отримайте детальну діагностику імпорту, включно з destroyed pools (-D)

cr0x@server:~$ zpool import -D -d /dev/disk/by-id
pool: tank
  id: 9876543210987654321
state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing devices and try again.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-3C
config:

        tank                         UNAVAIL  missing device
          raidz1-0                   UNAVAIL
            wwn-0x5000cca2abcd0001   ONLINE
            wwn-0x5000cca2abcd0002   ONLINE
            wwn-0x5000cca2abcd0003   UNAVAIL

Що це означає: ZFS чітко вказує відсутнього члена. Це не проблема найменування; він відсутній/нечитабельний.

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

Task 3: Підтвердіть, що ядро бачить помилки збереження

cr0x@server:~$ dmesg -T | egrep -i "zfs|sd |sas|nvme|ata|reset|timed out|I/O error" | tail -n 12
[Thu Dec 26 10:12:09 2025] sd 2:0:3:0: timing out command, waited 180s
[Thu Dec 26 10:12:09 2025] sd 2:0:3:0: [sdd] tag#24 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Thu Dec 26 10:12:10 2025] blk_update_request: I/O error, dev sdd, sector 2048 op 0x0:(READ)
[Thu Dec 26 10:12:12 2025] ata4: hard resetting link
[Thu Dec 26 10:12:18 2025] sd 2:0:3:0: [sdd] Synchronizing SCSI cache

Що це означає: Це не драматизація ZFS. ОС не може надійно читати з пристрою.

Рішення: Припиніть пробувати випадкові прапорці імпорту. Стабілізуйте апаратний шлях (заміна диска/кабелю/порту HBA) або очікуйте лише часткове відновлення.

Task 4: Перевірте, що використовуєте стабільні ідентифікатори пристроїв

cr0x@server:~$ ls -l /dev/disk/by-id | egrep "wwn|nvme|ata" | head
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0001 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0002 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0003 -> ../../sdd
lrwxrwxrwx 1 root root 13 Dec 26 10:10 nvme-SAMSUNG_MZVL21T0HCLR-00000_S6Z7... -> ../../nvme0n1

Що це означає: У вас є WWN-силінки; це саме те, що ZFS хоче для стабільного імпорту.

Рішення: При ручному імпорті вказуйте ZFS директорію /dev/disk/by-id через zpool import -d. Якщо пул було створено з /dev/sdX, сплануйте ремедіацію (export/import або оновлення конфігурації) коли система стабільна.

Task 5: Визначте, які диски справді містять ZFS-мітки

cr0x@server:~$ for d in /dev/disk/by-id/wwn-*; do echo "== $d =="; zdb -l $d 2>/dev/null | egrep "name:|pool_guid|vdev_guid|state:"; done | head -n 20
== /dev/disk/by-id/wwn-0x5000cca2abcd0001 ==
    name: 'tank'
    state: 0
    pool_guid: 9876543210987654321
== /dev/disk/by-id/wwn-0x5000cca2abcd0002 ==
    name: 'tank'
    state: 0
    pool_guid: 9876543210987654321
== /dev/disk/by-id/wwn-0x5000cca2abcd0003 ==
    name: 'tank'
    state: 1
    pool_guid: 9876543210987654321

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

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

Task 6: Перевірте hostid і властивості multihost, щоб пояснити «використовується»

cr0x@server:~$ hostid
7f01000a
cr0x@server:~$ zpool get multihost tank
NAME  PROPERTY  VALUE     SOURCE
tank  multihost  on        local

Що це означає: multihost=on робить ZFS більш строгим щодо одночасного доступу. Зміни hostid (клонований образ ОС) можуть викликати попередження.

Рішення: Якщо це справжнє локальне сховище для одного хоста, розгляньте можливість встановлення multihost=off пізніше. Зараз підтвердіть ексклюзивність і використовуйте -f лише коли можете це обґрунтувати.

Task 7: Спробуйте read-only import (режим безпечного огляду)

cr0x@server:~$ zpool import -o readonly=on -N -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          raidz1-0                   DEGRADED     0     0     0
            wwn-0x5000cca2abcd0001   ONLINE       0     0     0
            wwn-0x5000cca2abcd0002   ONLINE       0     0     0
            wwn-0x5000cca2abcd0003   UNAVAIL      0     0     0  cannot open

Що це означає: Пул можна відкрити без монтування datasets (-N) і без записів (readonly=on).

Рішення: Це зелений сигнал: змонтуйте datasets у режимі лише для читання і скопіюйте критичні дані, або замініть відсутній диск і дочекайтесь resilver.

Task 8: Імпорт без лог-пристрою (якщо був окремий SLOG)

cr0x@server:~$ zpool import -m -d /dev/disk/by-id tank
cannot import 'tank': one or more devices is currently unavailable
cr0x@server:~$ zpool import -m -o readonly=on -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank | egrep -i "logs|missing|unavail"
logs
  wwn-0x5000cca2beef0009   UNAVAIL  cannot open

Що це означає: Відсутній пристрій — це log vdev. ZFS часто дозволяє імпортуватися без нього з -m, якщо основні vdev-и цілі.

Рішення: Імпортуйте без логу, прийміть падіння продуктивності та плануйте видалення/заміну log vdev правильно, коли система стане стабільною.

Task 9: Перевірте служби імпорту ZFS та помилки при завантаженні

cr0x@server:~$ systemctl status zfs-import-cache zfs-import-scan --no-pager
● zfs-import-cache.service - Import ZFS pools by cache file
     Loaded: loaded (/lib/systemd/system/zfs-import-cache.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-26 10:01:21 UTC; 3min ago
   Process: 812 ExecStart=/sbin/zpool import -c /etc/zfs/zpool.cache -aN (code=exited, status=1/FAILURE)

● zfs-import-scan.service - Import ZFS pools by device scanning
     Loaded: loaded (/lib/systemd/system/zfs-import-scan.service; enabled)
     Active: inactive (dead)

Що це означає: Імпорт за cachefile не вдався, а scan-based import не запустився (або не увімкнений). Класичний «пул імпортується вручну, але не при завантаженні».

Рішення: Виправте cachefile або увімкніть scan import. Також дослідіть, чому пристрої не були готові, коли cache import запускався.

Task 10: Прочитайте журналі для підказок по імпорту ZFS (зазвичай прямолінійний)

cr0x@server:~$ journalctl -u zfs-import-cache -u zfs-import-scan -b --no-pager | tail -n 40
Dec 26 10:01:20 server zpool[812]: cannot import 'tank': one or more devices is currently unavailable
Dec 26 10:01:20 server zpool[812]: Destroy and re-create the pool from a backup source.
Dec 26 10:01:20 server systemd[1]: zfs-import-cache.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 10:01:21 server systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.

Що це означає: Імпорт не вдався з тієї самої причини, що й у ручному запуску. Це не «systemd drama»; це доступність пристроїв.

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

Task 11: Перевірте конфлікти multipath (поширено для SAN/iSCSI/FC)

cr0x@server:~$ multipath -ll | head -n 25
mpatha (3600508b400105e210000900000490000) dm-2 IBM,2145
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Що це означає: Той самий LUN видимий через кілька шляхів і агрегований у /dev/dm-2 як mpatha.

Рішення: Переконайтеся, що ZFS використовує multipath-пристрій послідовно (dm-id) і ви не імпортуєте випадково через сирі шляхи /dev/sdb//dev/sdc. Дубльована видимість може призвести до корупції, якщо її неправильно оброблено.

Task 12: Перевірте сумісність feature пулу (особливо у rescue-середовищах)

cr0x@server:~$ zpool import -o readonly=on -N tank
cannot import 'tank': unsupported feature(s)
This pool uses the following feature(s) not supported by this system:
        org.openzfs:encryption
        org.openzfs:project_quota

Що це означає: Ваше поточне userspace/kernel ZFS не може розпізнати пул. Це типово при завантаженні старого live ISO.

Рішення: Завантажте версію Proxmox (або rescue-середовище) із сучасним OpenZFS, що підтримує ці фічі. Не намагайтеся «ремонтувати» пул з несумісного середовища.

Task 13: Завантажте ключі шифрування і змонтуйте datasets (кейс «пул імпортовано, але нічого не працює»)

cr0x@server:~$ zpool import -N -d /dev/disk/by-id tank
cr0x@server:~$ zfs get -r -o name,property,value keystatus tank | head
NAME          PROPERTY   VALUE
tank/secure   keystatus  unavailable
tank/vmdata   keystatus  available
cr0x@server:~$ zfs load-key -r tank/secure
Enter passphrase for 'tank/secure':
cr0x@server:~$ zfs mount -a
cr0x@server:~$ zfs get -r -o name,mounted,mountpoint mounted tank/secure | head -n 3
NAME         MOUNTED  MOUNTPOINT
tank/secure  yes      /tank/secure

Що це означає: Імпорт пулу пройшов. Проблема була в заблокованих datasets.

Рішення: Виправте управління ключами (prompting при завантаженні vs keyfiles vs зовнішній KMS). Не гоніться за примарними «помилками імпорту» в GUI.

Task 14: Переконайтеся, що пул вже не імпортовано (таке буває)

cr0x@server:~$ zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  5.45T  3.12T  2.33T        -         -    18%    57%  1.00x  ONLINE  -
cr0x@server:~$ pvesm status | head
Name             Type     Status           Total            Used       Available        %
local             dir     active       102399872        4823424        972...          4%

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

Рішення: Перейдіть від «імпорту» до «чому Proxmox не використовує пул»: перевірте mountpoint-и datasets, /etc/pve/storage.cfg і права доступу.

Task 15: Спробуйте примусовий імпорт (тільки після доведення ексклюзивності)

cr0x@server:~$ zpool import -f -d /dev/disk/by-id rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          sda3      ONLINE       0     0     0

Що це означає: Попередження «in use» було усунуте через forced import.

Рішення: Якщо цей пул коли-небудь буде видимий іншому хосту, виправте модель fencing/ownership. Force import — інструмент, а не спосіб життя.

Варіанти відновлення, ранжовані за ризиком

Tier 0: Не ускладнюйте ситуацію

• Уникайте zpool clear як рефлексу. Воно очищає помилки; не виправляє причину.
• Уникайте запису в пул, який ви не верифікували. При сумнівах спочатку імпортуйте read-only.
• Уникайте zpool labelclear, якщо тільки ви навмисно не знищуєте мітки (і впевнені, що на правильних дисках).
• Уникайте «спробувати випадкові прапорці, поки не спрацює». Так ви перетворите відновлюваний пул на кримінальний артефакт.

Tier 1: Безпечні імпорти та огляд

• Read-only import: zpool import -o readonly=on -N ... дозволяє огляд без змін на диску.
• No-mount import: -N запобігає монтуванню datasets, щоб ви могли виправити mountpoints або ключі свідомо.
• Явна директорія пристроїв: -d /dev/disk/by-id уникає рулетки з іменами пристроїв.

Tier 2: Контрольовані перевищення для відомих сценаріїв

• Force import (-f): лише коли ви довели, що пул не імпортований десь ще і ви контролюєте всі шляхи.
• Missing log (-m): якщо відсутній окремий SLOG. Імпортуйте, потім правильно видаліть/замініть log vdev.
• Імпорт з альтернативним коренем (-R /mnt): змонтуйте datasets під тимчасовим коренем для рятувального копіювання без порушення звичних mountpoint-ів.

Tier 3: Degraded імпорти та евакуація даних

• Імпорт у деграді, коли є надлишковість і відсутній один пристрій. Імпортуйте read-only, якщо не впевнені в стані залишкових дисків.
• Копіювання назовні критичних дисків ВМ і конфігів негайно. Якщо диск відмовляє, resilver додає навантаження; копіювання теж — виберіть шлях, який якнайшвидше вивезе дані.

Tier 4: Останні засоби

• Глибоке відновлення з інструментами ZFS (zdb у поглиблених режимах) інколи може витягти інформацію, але в цій точці треба вважати пул нестабільним і пріоритетизувати вивезення даних.
• Професійне відновлення для безцінних даних без надлишковості. Якщо ви думаєте «можливо ми просто продовжимо пробувати», ви, ймовірно, ось-ось зітрете останні читабельні метадані.

Одна перефразована ідея від Werner Vogels: «Everything fails all the time.» ZFS побудований з урахуванням відмов. Ваші операційні практики теж повинні бути такими.

Жарт #1: ZFS не «втрачав» ваші диски; він просто змусив вас нарешті вивчити, який кабель куди йде.

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

1) «Немає пулів для імпорту» після перенесення дисків

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

Коренева причина: Ви скануєте неправильний простір пристроїв (наприклад, за multipath), або HBA не презентує диски, або завантажено ядро без потрібного драйвера.

Виправлення: Перевірте диски в lsblk, дивіться dmesg для приєднання драйвера, скануйте з zpool import -d /dev/disk/by-id, та вирішіть multipath на один канонічний набір пристроїв.

2) «Pool may be in use from another system» і люди пхають -f бездумно

Симптом: Імпорт просить -f.

Коренева причина: Можливий спільний доступ (SAN, shared JBOD, випадковий dual-path). Або hostid змінився через клонування.

Виправлення: Доведіть ексклюзивність (фізично або через контроль доступу на боці таргета). Потім використовуйте zpool import -f. Якщо hostid нестабільний, виправте /etc/hostid і уникайте клонування образів ОС без регенерації.

3) Пул імпортується, але сховище Proxmox все одно виглядає мертвим

Симптом: zpool list показує пул онлайн, але GUI сховище «неактивне» або ВМ не стартують.

Коренева причина: Datasets не змонтовані, mountpoints змінились, ключі шифрування не завантажені, або /etc/pve/storage.cfg вказує на dataset, якого більше немає.

Виправлення: zfs mount -a, перевірте zfs get mountpoint,mounted, завантажте ключі і звірте /etc/pve/storage.cfg з реальними datasets/ZVOL-ами.

4) Імпорт не вдається лише при завантаженні, а вручну працює

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

Коренева причина: Виявлення пристроїв затримується (ініціалізація HBA, iSCSI login, multipath), і cache-based import запускається занадто рано або вказує на застарілі шляхи.

Виправлення: Увімкніть scan import як резерв, виправте порядок iSCSI/multipath, згенеруйте /etc/zfs/zpool.cache через clean export/import під час maintenance і забезпечте залежності служб від готовності сховища.

5) «Unsupported feature(s)» у rescue-режимі

Симптом: Пул видно, але відмовляє імпорт з переліком фіч.

Коренева причина: Rescue-середовище використовує старіший OpenZFS, ніж пул вимагає.

Виправлення: Використовуйте сучасне середовище Proxmox/kernel/userspace, що відповідає фічам пулу. Не оновлюйте пул на одному хості без плану на recovery-середовища.

6) Спроба degraded імпорту на непереможному пулі

Симптом: Однодисковий пул втратив єдиний диск, або mirror втратив одну сторону з мовчазною корупцією.

Коренева причина: Відсутня надлишковість або обидві сторони постраждали; ZFS не може викликати блоки з фізики.

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

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

Чекліст A: триаж «пул не імпортується» за 15 хвилин

1. Підтвердіть ексклюзивність: переконайтеся, що ніякий інший хост не бачить дисків/LUN-ів.
2. Запустіть zpool import і зафіксуйте точне повідомлення.
3. Перевірте наявність пристроїв: lsblk -o NAME,SIZE,MODEL,SERIAL і ls -l /dev/disk/by-id.
4. Проскануйте ядро на помилки: dmesg -T | tail і шукайте timeouts/resets.
5. Спробуйте read-only no-mount import: zpool import -o readonly=on -N -d /dev/disk/by-id POOL.
6. Якщо імпортується: перевірте zpool status і вирішіть «resilver vs копіювання даних назовні».
7. Якщо не імпортується: перевірте feature flags, відсутні пристрої та сигнали hostid/multihost.

Чекліст B: робочий процес відновлення при відсутності vdev, але є надлишковість

1. Спочатку імпорт read-only, щоб валідувати стабільність залишкових пристроїв.
2. Зберіть zpool status -v і лічильники помилок; якщо вони ростуть у стані спокою, апарат все ще хворий.
3. Замініть/відновіть відсутній шлях до диска (заміна диска, пересадження, виправлення multipath).
4. Імпортуйте read-write і почніть resilver, коли впевнені, що шина стабільна.
5. Моніторте прогрес resilver і журнали системи на предмет reset/timeout.
6. Після resilver виконайте scrub.

Чекліст C: помилки імпорту під час завантаження

1. Переконайтеся, що ручний імпорт працює стабільно.
2. Перевірте systemctl status zfs-import-cache zfs-import-scan.
3. Перегляньте порядок для iSCSI/multipath (якщо використовується): пристрої повинні бути доступні до запуску імпорту ZFS.
4. Згенеруйте cachefile заново через чистий export/import під час maintenance.
5. Перезавантажте один раз. Якщо працює — перезавантажте ще раз. Не оголошуйте перемогу після одного вдалого завантаження.

Жарт #2: «Працює після ребуту» — це не виправлення; це сюжетний поворот.

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

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

Середня компанія працювала на двох вузлах Proxmox зі спільним SAS-шельфом. Хтось назвав це «ніби SAN, але дешевше», і по тому можна зрозуміти, що воно стане дорогим пізніше.
Вони поставили ZFS поверх спільного шельфу, бо «в тестах працювало».

Одного дня вузол перезавантажився після оновлення ядра. Пул не автоімпортнувся, і інженер на виклику зробив те, що роблять нетерплячі люди:
запустив zpool import -f, бо інструмент порадив це. Пул піднявся. ВМ стартували. Всі взяли подих.

Інший вузол, який також мав фізичний доступ до шельфу, був налаштований на імпорт того ж пулу для попереднього експерименту.
Він не імпортувався у той момент, але був налаштований так, що іноді торкався пристроїв через моніторинг та udev.
Через кілька годин запланований таск запустив імпорт там теж, і він теж використав -f, бо так було в runbook.

Вони отримали класичний split-brain. ZFS робив все, що міг, але жодна файлова система не може примирити двох писачів одночасно без координації.
Корупція не була миттєвою; вона проявилася як «випадкові» помилки дисків ВМ і повільне руйнування довіри.

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

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

Інша команда працювала з Proxmox і ZFS поверх iSCSI LUN-ів. Це може працювати, але це угода з дияволом: треба управляти multipath стабільно і уникати churn пристроїв.
Вони хотіли швидших імпортів і завантажень, тому налаштували імпорти на cachefile, відключили scan import і скоротили «непотрібні» затримки при завантаженні.

Все було нормально, поки плановий failover контролера SAN не змусив LUN-и з’являтися на кілька секунд пізніше під час завантаження.
zfs import-cache запустився рано, не побачив очікуваних пристроїв і впав. Оскільки scan import був вимкнений, ніхто не спробував повторити.
Proxmox запустився без сховища. Кластер думав, що вузол живий, але без рук, що тримає дані — досить сумна комбінація.

Інженер вручну імпортував і все працювало. Ось де підступ: ручні виправлення дають ілюзію надійності.
Але це траплялося при кожному холодному старті, і лише у дні, коли SAN вирішував пограти драму.

Зрештою вирішення було нудним: увімкнули scan import як fallback, додали залежності, щоб iSCSI login і multipath завершувалися до імпорту ZFS,
і згенерували cachefile після підтвердження стабільного by-id найменування. Завантаження стало трохи повільнішим. Uptime — значно надійнішим.

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

Компанія з фінансового сектору мала Proxmox на дзеркальних завантажувальних дисках і окремий пул ZFS для VM-ів. Нічого екзотичного: HBA в IT-режимі, диски з WWN,
datasets названі по-діловому і щомісячні звіти scrub, які ніхто не читає — поки не почали читати.

Одного ранку після стрибка напруги вузол відмовив імпортувати VM-пул. Помилка була «one or more devices is currently unavailable».
Замість паніки вони слідували своєму чеклісту: підтвердили інвентар пристроїв, перевірили dmesg, спробували read-only import.
Пул імпортувався degraded; один диск справді пішов.

Ключовий момент: завдяки регулярним scrub-ам вони вже знали, що залишкові диски були чисті тиждень тому.
Це змінило рішення. Вони імпортували read-write, замінили відмовлений диск, дочекавшись resilver, і зробили scrub знову.
Простої ВМ вклиналися у maintenance-вікно, а не в перейменування кар’єри.

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

FAQ

1) Чи завжди слід використовувати zpool import -f, якщо ZFS радить це?

Ні. Використовуйте -f лише коли довели, що пул не імпортований в іншому місці і ніхто інший не може писати на ці пристрої.
На спільному сховищі force-import — це як купити корупцію терміново.

2) Що зазвичай означає «no pools available to import» на Proxmox?

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

3) Якщо я можу імпортувати read-only, чи означає це, що пул безпечний?

Це сильний сигнал, що основні метадані читабельні та узгоджені, але це не гарантія майбутньої стабільності.
Апарат може деградувати під навантаженням. Використайте read-only import для огляду, потім вирішіть, чи робити resilver або евакуацію даних першими.

4) Чому Proxmox іноді не імпортує при завантаженні, але ручний імпорт працює?

Через порядок завантаження. Пристрої з’являються пізно (ініціалізація HBA, iSCSI login, settling multipath), тоді як служби імпорту ZFS запускаються раніше.
Виправте порядок і fallback-механізми; не покладайтеся на «хтось виконає команду вручну».

5) Чи можна «понизити» ZFS пул, щоб імпортувати на старішому Proxmox?

Ні. Якщо пул має feature flags, які не підтримуються старшим середовищем, потрібне новіше середовище для імпорту.
Плануйте оновлення з урахуванням інструментів для відновлення.

6) Пул імпортовано, але datasets не змонтовані. Це помилка імпорту?

Зазвичай ні. Це проблема монтування/ключа/mountpoint-у. Перевірте zfs mount, zfs get mounted,mountpoint і keystatus шифрування.
Proxmox може виглядати «вниз», коли насправді сховище «заблоковане» або «не змонтоване».

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

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

8) Чи допомагає очищення помилок zpool clear при проблемах з імпортом?

Рідко. Воно очищає лічильники помилок і може повторно активувати пристрій після транзитної помилки, але не виправляє таймаути, кабелі,
відмову дисків, дублювання multipath або unsupported features.

9) Яка найкраща стратегія шляхів пристроїв для Proxmox ZFS пулів?

Використовуйте /dev/disk/by-id (WWN або NVMe серійний) послідовно. Уникайте /dev/sdX.
Якщо ви використовуєте SAN/multipath, забезпечте, щоб ZFS використовував один канонічний набір пристроїв (зазвичай dm-id) і ніколи обидва — сирі і multipath вузли.

10) Коли доречно використовувати zpool import -m?

Коли окремий log-пристрій (SLOG) відсутній і заважає імпорту. Це дозволяє імпортувати без цього логу.
Після цього потрібно видалити/замінити відсутній log vdev, щоб уникнути повторних попереджень і дивних станів.

Висновок: кроки, які можна зробити сьогодні

«Не вдається імпортувати пул» — це не одна проблема. Це сімейство симптомів. Найшвидший шлях назовні — дисциплінований триаж:
перевірте пристрої, прочитайте точну скаргу ZFS, імпортуйте read-only при сумніві, і переходьте до force/degraded імпортів лише з чітким аргументом безпеки.

Практичні кроки, що зменшать біль у майбутньому:

• Стандартизувати використання /dev/disk/by-id для всіх пулів і документувати відповідність WWN до фізичного слоту.
• Зробити «доведіть ексклюзивність» обов’язковим перед -f для будь-якого сховища, здатного до спільного доступу.
• Тестувати відновлення в сучасному середовищі, яке може імпортувати feature-набір вашого пулу (особливо шифрування).
• Увімкнути і моніторити scrub-и, і трактувати звіти scrub як операційні сигнали, а не фон.
• Виправити порядок завантаження, якщо ви покладаєтеся на iSCSI/multipath; ручні імпорти не є SLO.

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