Пул ZFS не импортируется: что делать по шагам

Пул ZFS не импортируется: с чего начать

Если пул ZFS не импортируется после перезагрузки, замены диска или переноса дисков на другой сервер, первая команда всегда одна и та же: zpool import без аргументов. Она ничего не записывает на диски, а только показывает, какие пулы система видит и из каких устройств они собраны. Дальше идите по возрастанию риска, потому что хвост этой цепочки необратим.

Порядок ровно такой: посмотреть, что видно; подсказать системе, где искать устройства; импортировать только для чтения; и лишь в самом конце, если иначе никак, откатить последние транзакции. Тот, кто начинает с последнего шага, теряет данные, которые ещё можно было скопировать целиком.

ZFS (файловая система и менеджер томов в одном) держит на каждом устройстве по четыре копии метки с описанием пула. Пока читается хотя бы часть меток, пул существует, даже если он не смонтирован. Импорт: это не «починка», а сборка пула из найденных устройств и передача его ядру. В Ubuntu 24.04 всё ниже относится к OpenZFS 2.2, который поставляется пакетом zfsutils-linux (по состоянию на сентябрь 2026).

Команды в этом руководстве выполняет читатель на своей машине. Импорт пула требует загруженного модуля ядра zfs и устройства /dev/zfs, поэтому проверить их в обычном контейнере нельзя, и этот текст не является сценарием для контейнера.

Что показывает zpool import без аргументов

sudo zpool import

Команда сканирует блочные устройства в /dev, читает метки и печатает всё, что нашла: имя пула, его числовой идентификатор, состояние и дерево устройств. Ничего не монтируется и ничего не пишется, поэтому шаг безопасен даже в разгар аварии.

Читайте результат сверху вниз и отвечайте себе на три вопроса. Виден ли пул вообще. Все ли устройства на месте, или часть помечена как недоступная. Есть ли подсказка о том, что импорт нужно выполнить принудительно.

Состояния устройств в ZFS стоит знать наизусть: ONLINE (устройство работает), DEGRADED (работает с потерей избыточности), FAULTED (ZFS не доверяет устройству), UNAVAIL (устройство не открылось), REMOVED (устройство исчезло из системы). Пул в состоянии DEGRADED импортируется и работает. Пул, где в одной группе избыточности выпало больше устройств, чем она способна пережить, не импортируется вообще, и никакой флаг этого не изменит.

Пул не виден: ZFS не нашла метки

Если zpool import не показал ни одного пула, проблема лежит ниже ZFS. Устройств просто нет в том виде, в каком их ждёт сканер.

lsblk -o NAME,SIZE,TYPE,FSTYPE,SERIAL
ls -l /dev/disk/by-id/
sudo zdb -l /dev/disk/by-id/<ваше-устройство>-part1

lsblk показывает, доехали ли диски до системы. На VPS диск, который вы подключаете к rescue-инстансу или ко второму серверу, иногда просто не подключён в панели провайдера, и дальше искать нечего. zdb -l читает метки конкретного устройства. Если метки найдены, ZFS о пуле знает, и дело в путях поиска. Если меток нет ни на одном разделе, вы смотрите не на то устройство или не на тот раздел, потому что vdev обычно живёт в первом разделе диска, а не в диске целиком.

Частые причины, по которым устройство есть, а меток не видно. Контейнер LUKS не открыт, и ZFS видит зашифрованный шум: сначала cryptsetup open, потом импорт. Диск занят другой подсистемой, например multipath или mdadm. Раздел был пересоздан установщиком или разметчиком, и метки затёрты: это уже не задача импорта.

Родное шифрование ZFS ведёт себя иначе. Пул с зашифрованными датасетами импортируется нормально, а данные остаются недоступны до zfs load-key -a. Это не отказ импорта.

Два пула с одинаковым именем: импорт по числовому id

tank на новом сервере и tank на принесённых дисках: обычная ситуация, в которой имя перестаёт быть адресом. У каждого пула есть числовой идентификатор, и zpool import печатает его рядом с именем. Импортируйте по идентификатору и сразу переименуйте пул.

sudo zpool import <числовой-id> tank-old

Второй аргумент задаёт новое имя пула в этой системе. Оно записывается в метки, поэтому после возврата дисков на родной сервер пул будет называться уже по-новому. Числовой идентификатор при переименовании не меняется, он остаётся постоянным адресом пула.

Устройства переехали: -d /dev/disk/by-id

Имена вида /dev/sdb назначаются в порядке обнаружения. Добавили диск, поменяли порядок подключения в панели VPS, перезагрузились: то, что было sdb, стало sdc. Сам пул от этого не ломается, потому что ZFS ищет метки, а не имена. Ломается конфигурация, в которой пути были зафиксированы как /dev/sdX.

sudo zpool import -d /dev/disk/by-id
sudo zpool import -d /dev/disk/by-id -d /dev/mapper tank

Флаг -d говорит, в каком каталоге или на каком конкретном устройстве искать метки, и его можно указывать несколько раз. Для LUKS добавьте /dev/mapper, для файловых vdev укажите каталог с файлами.

Когда пул поднялся, закрепите стабильные пути. Экспорт и повторный импорт по by-id перезаписывают пути в конфигурации пула.

sudo zpool export tank
sudo zpool import -d /dev/disk/by-id tank
zpool status -v

Идентификаторы в /dev/disk/by-id собираются из модели и серийного номера, поэтому они переживают перезагрузку и смену порядка дисков. Это одно из решений, которые дешевле принять при создании пула, чем менять потом, как и параметры пула, которые уже нельзя поменять после создания.

-f: что значит «пул использовался другой системой»

При импорте ZFS записывает в метки hostid и имя хоста той машины, которая владеет пулом. Чистый zpool export эту запись снимает. Если снять её не успели, любая другая машина увидит чужой hostid, откажется импортировать пул сама и сообщит, что пул последний раз использовался другой системой, а также предложит флаг -f.

Это сообщение не про повреждение данных. Вы увидите его в трёх обычных ситуациях: сервер выключился жёстко и не успел экспортировать пул; диск переехал в rescue-инстанс или на вторую VPS; hostid изменился на той же машине, например после пересборки initramfs или переустановки системы поверх.

sudo zpool import -f tank

Опасность у -f ровно одна, и она настоящая. Если те же блочные устройства прямо сейчас подключены к живой второй машине, которая держит пул импортированным, параллельный импорт разрушит пул за секунды, потому что два независимых писателя пишут в одни и те же блоки без всякой координации. Перед -f убедитесь, что вторая машина выключена или диски от неё отключены.

Для разделяемого хранилища у ZFS есть защита: свойство multihost=on включает MMP (multi modifier protection), при которой хосты периодически обновляют метку и видят чужую активность. Она удлиняет импорт, зато делает описанный сценарий почти невозможным. На обычной VPS с локальными дисками она не нужна.

Сначала только чтение: -o readonly=on и -R /mnt

Если данные важны, первый настоящий импорт делайте в режиме только для чтения. Пул не изменится, журнал намерений ZIL (ZFS intent log) не будет проигран, и любая следующая попытка начнётся ровно с того же состояния, что и сейчас.

sudo zpool import -o readonly=on -R /mnt -N tank
zfs list -r tank
sudo zfs mount tank/data

-R /mnt задаёт альтернативный корень: все точки монтирования датасетов получают префикс /mnt, поэтому пул с mountpoint=/ или /var не перекроет каталоги работающей системы. Альтернативный корень заодно отключает запись пула в cachefile, так что такой импорт не повлияет на следующую загрузку.

-N импортирует пул, ничего не монтируя. Это удобно, когда вы ещё не знаете, куда датасеты попросятся, и хотите смонтировать их по одному.

Дальше забирайте данные, пока пул доступен. В режиме только для чтения нельзя создать снапшот, поэтому либо копируйте файлы обычным rsync, либо отправляйте уже существующий снапшот.

sudo zfs send tank/data@daily-2026-09-26 | ssh backup@storage 'zfs receive -u pool/restore'

Если снапшоты на пуле есть, ваше положение намного лучше, чем кажется в первые минуты. Откат датасета к снапшоту и откат пула по транзакциям это разные операции с разной ценой, и первая разобрана в материале про снапшоты, клоны и откат датасета.

Пул импортируется, но устройство в состоянии FAULTED

Пул в DEGRADED работает, и это не повод для паники. Повод для срочности: избыточности больше нет, и следующий сбой диска станет потерей пула.

sudo zpool status -v tank
sudo smartctl -a /dev/disk/by-id/<устройство>
sudo zpool clear tank

zpool clear сбрасывает счётчики ошибок и возвращает устройство в работу, если сбой был разовым, например по шине или после отключения питания. Если SMART показывает растущие переназначенные секторы или ошибки чтения, не сбрасывайте счётчики, а меняйте диск: zpool replace tank <старое> <новое> запустит ресилверинг. Диски предупреждают заранее, поэтому мониторинг состояния дисков на VPS превращает будущую аварию в плановую замену.

Отдельный случай: пропал выделенный log-диск (SLOG). Такой пул может не импортироваться, пока устройства нет, потому что ZFS не знает, что было в журнале. Флаг -m импортирует пул без пропавшего log-устройства и отбрасывает содержимое журнала, то есть последние синхронные записи. Потерянные кэш-устройство L2ARC или горячий резерв импорту не мешают никогда.

sudo zpool import -m tank

Откат транзакций: -F, -FX и цена вопроса

ZFS пишет группами транзакций (transaction group, txg), и каждая группа завершается обновлением uberblock, корневой записи пула. Если последние записанные группы не читаются, пул не собирается, хотя более раннее состояние на дисках цело. Флаг -F откатывает пул на последнюю исправную группу транзакций.

Сначала проверка без записи. Флаг -n работает только вместе с -F и сообщает, получится ли восстановить пул таким способом, ничего при этом не меняя.

sudo zpool import -F -n tank

Если проверка говорит, что импорт возможен, выполняйте откат.

sudo zpool import -F tank

Говоря прямо: откат меняет последние секунды записи на работающий пул. Теряется всё, что попало в отброшенные группы транзакций. На практике это секунды или десятки секунд, потому что группа закрывается по таймеру (порядка пяти секунд по умолчанию) или по заполнению. Для файлового хранилища это обычно несколько недописанных файлов. Для базы данных или образа виртуальной машины это состояние, которое приложению придётся доводить до порядка своими средствами: ZFS вернёт консистентный пул, но не консистентную базу.

-X расширяет поиск. ZFS перебирает более старые uberblock и проверяет пул глубже, работа может занять часы, а отброшено будет заметно больше. Комбинация -FX это последняя дверь перед восстановлением из резервной копии, а не второй по счёту шаг.

sudo zpool import -FX tank

-T <txg> вместе с -X позволяет указать группу транзакций вручную. Брать этот флаг стоит только тогда, когда вы читали список uberblock через zdb -ul по устройству и понимаете, какую точку выбираете.

Правило, которое спасает пулы: если диски физически подозрительные, сначала снимите посекторные образы утилитой ddrescue, а опыты ставьте на копиях. zpool import -d ищет метки и в каталоге с файлами, поэтому образы, подключённые через losetup -P, импортируются так же, как настоящие диски.

Скраб после отката не опция

После любого -F или -FX сразу запускайте скраб. Откат вернул целостность на уровне метаданных, но не прочитал ни одного блока данных и ни одной контрольной суммы.

sudo zpool scrub tank
zpool status -v tank

После скраба zpool status -v перечислит файлы с постоянными ошибками поимённо. Эти файлы восстанавливают из копии, потому что читаются они уже с ошибкой, и никакая избыточность их больше не спасёт. Дальше вернитесь к нормальному расписанию проверок, как в расписании скраба для небольших пулов: регулярный скраб находит тихую порчу до того, как она совпадёт с аварией.

Пул импортируется руками, но не поднимается при загрузке

Это отдельная проблема, и она не про данные. При импорте ZFS запоминает конфигурацию пула в файле /etc/zfs/zpool.cache, а служба zfs-import-cache.service импортирует при загрузке именно то, что там записано. Импорт с -R кэш не обновляет, поэтому после ручного восстановления пул часто остаётся невидимым для следующей загрузки.

sudo zpool set cachefile=/etc/zfs/zpool.cache tank
systemctl status zfs-import-cache.service zfs-mount.service
sudo systemctl enable zfs-import-cache.service zfs.target

Альтернатива кэшу это zfs-import-scan.service, которая при загрузке сканирует устройства и импортирует найденные пулы. Включать обе службы одновременно не нужно. Если на ZFS стоит корень системы, после изменения кэша пересоберите initramfs командой sudo update-initramfs -u -k all, иначе ранняя стадия загрузки продолжит использовать старую копию файла.

Чего делать нельзя

zpool create поверх тех же устройств: это не пересоздание старого пула, а новый пул и затёртые метки. zpool labelclear на устройстве живого пула делает то же самое, только точечно. Утилиты в духе fsck: для ZFS их не существует, и поиск такой команды приводит к чужому скрипту, который перепишет разметку. Наконец, -FX первым действием: сначала обычный zpool import, потом режим только для чтения, и лишь затем откат.

Исход решает копия, которая лежит не здесь

Всё выше это способы прочитать пул, который уже сломан. Когда метки затёрты или выпало больше дисков, чем переживает избыточность, ни один флаг не поможет, потому что данных на дисках больше нет. Пул, который не импортируется, восстанавливается ровно настолько, насколько существует его копия на другой машине, и это единственная часть истории, которой вы управляете заранее.

Рабочий минимум выглядит так: снапшоты по расписанию плюс регулярная отправка их на отдельный сервер, чтобы копия жила на других дисках и в другом здании. Как это настроить и сколько занимает первая полная отправка, разобрано в переносе снапшотов через zfs send на storage VPS. И помните, что снапшот внутри того же пула резервной копией не является: разница разобрана в сравнении снапшотов VPS и настоящих бэкапов.

FAQ

Почему zpool import пишет, что пул использовался другой системой?

В метках пула хранится hostid машины, которая его импортировала, и чистый zpool export эту запись снимает. Если экспорта не было, любой другой хост увидит чужой hostid и откажется импортировать пул без флага -f. Так бывает после жёсткого выключения, при переносе диска в rescue-инстанс или на вторую VPS, а также на той же машине, если hostid изменился после переустановки системы. Повреждения данных это сообщение не означает. Перед -f убедитесь только в одном: те же диски не подключены сейчас к работающей второй машине, потому что два одновременных писателя разрушат пул.

Что теряется при zpool import -F?

Все записи, попавшие в отброшенные группы транзакций, то есть последние секунды работы пула. Группа транзакций закрывается по таймеру (порядка пяти секунд по умолчанию) или по заполнению, поэтому речь обычно идёт о недописанных файлах, а не о каталогах целиком. Сначала выполните zpool import -F -n: эта проверка ничего не пишет и сообщает, возможен ли такой импорт. Для баз данных и образов виртуальных машин учитывайте, что пул станет консистентным, а приложение внутри придётся восстанавливать отдельно. -FX отбрасывает существенно больше и работает намного дольше.

Можно ли импортировать пул, если пропал отдельный log-диск (SLOG)?

Да, флагом -m. Он импортирует пул без пропавшего log-устройства и отбрасывает то, что оставалось в журнале намерений, то есть последние синхронные записи. Потерянное кэш-устройство L2ARC или горячий резерв импорту не мешают вообще, ZFS просто отметит их отсутствие. После такого импорта уберите мёртвое устройство из пула командой zpool remove и запустите скраб.

Пул импортируется вручную, но пропадает после перезагрузки. Это потеря данных?

Нет. Это состояние файла /etc/zfs/zpool.cache, по которому служба zfs-import-cache.service поднимает пулы при загрузке. Импорт с альтернативным корнем -R кэш намеренно не обновляет, поэтому после аварийного восстановления запись часто отсутствует. Выполните sudo zpool set cachefile=/etc/zfs/zpool.cache tank, проверьте, что служба импорта включена, и пересоберите initramfs, если на ZFS стоит корень системы. Данные в пуле при этом целы, проблема относится только к загрузке.