Восстановление пересозданного пула ZFS: что можно вернуть и в каких случаях

Короткий ответ: восстановление пересозданного пула ZFS возможно, если старые метаданные еще доступны для импорта, есть отдельная резервная копия или данные на исходных дисках не были перезаписаны. Сохраненная конфигурация помогает определить состав vdev и параметры пула, но сама по себе не возвращает файлы.

Если после zpool destroy на тех же дисках уже выполнен zpool create, ZFS записывает новые служебные метаданные. Любая запись в новый пул повышает риск перезаписи старых блоков. При отсутствии резервной копии и успешного импорта старого пула данные обычно считаются потерянными.

Сразу остановите операции записи, не запускайте новый zpool create, не выполняйте zpool labelclear и сначала проверьте, видит ли система уничтоженный пул через zpool import -D.

Что происходит при удалении и пересоздании пула ZFS

Пул ZFS объединяет диски в один или несколько vdev. На дисках хранятся пользовательские блоки, служебные labels, конфигурация vdev, метаданные файловой системы, MOS и записи о транзакциях. Для доступа к файлу ZFS должна найти не только сам блок данных, но и цепочку метаданных, которая описывает dataset, объект и его свойства.

Команда zpool destroy удаляет пул из рабочего состояния ZFS и помечает его служебную информацию как уничтоженную. Это не равно безопасному стиранию каждого сектора. Часть старых блоков может физически оставаться на HDD, SSD или NVMe, пока новые операции их не перезапишут.

После команды zpool create на тех же устройствах появляются новые labels, идентификатор пула, описание vdev и новые области метаданных. Старые данные могут остаться в свободных участках, но ZFS больше не знает, как связать их с исходными dataset и файлами. При последующих записях старые блоки постепенно заменяются новыми.

У ZFS нет штатной команды отмены zpool destroy. Команда zpool import -D иногда находит уничтоженный пул, если его labels и ключевые метаданные еще читаются. После пересоздания на тех же дисках такой сценарий быстро теряет применимость.

Удаление пула и подготовку дисков к повторному использованию нужно проводить осознанно. Перед началом процедуры полезно свериться с инструкцией по безопасному удалению пула ZFS, особенно если на дисках оставались снапшоты, zvol или несколько vdev.

Снапшот ZFS не помогает после уничтожения пула, если его единственная копия находилась внутри этого же пула. Снапшоты защищают от логических изменений, но не заменяют копию на отдельном носителе.

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

Первые действия определяют, сохранится ли исходная структура на дисках. Цель этого этапа - не восстановить файлы любой ценой, а не ухудшить состояние носителей.

1. Остановите запись. Выключите сервисы, которые могли использовать dataset, отключите автоматическое монтирование и остановите задания резервного копирования. Не создавайте на этих устройствах новый пул.
2. Не перезагружайте систему без необходимости. После перезапуска автозагрузка, контейнеры или виртуальные машины могут снова начать писать на диски. Если перезапуск неизбежен, сначала остановите сервисы и зафиксируйте состав устройств.
3. Проверьте диски. Сопоставьте имена устройств, размеры, модели и серийные номера. На Linux для первичной инвентаризации подойдет команда lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS. Ошибка с выбором диска опаснее самой команды импорта.
4. Сохраните доступные сведения. Скопируйте в отдельное место вывод zpool status, журналы, конфигурацию хоста и любые старые файлы zpool.cache. Не храните единственную копию этих данных на дисках проблемного пула.
5. Проверьте импорт. Сначала используйте команды, которые только читают сведения о доступных пулах. Запись выполняйте после оценки результата и только на копии носителей, если такая копия уже создана.

Проверка возможности импорта пула

Начните с обычного поиска пулов:

zpool import
zpool import -D

Первая команда ищет доступные для импорта пулы. Ключ -D добавляет поиск пулов, которые ZFS пометила как уничтоженные. В выводе проверьте имя пула, pool ID, состав vdev и состояние устройств. Сравните эти сведения с прежней конфигурацией.

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

zpool import -N -o readonly=on <имя_пула>

В некоторых версиях системы сначала требуется обычный импорт:

zpool import <имя_пула>

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

После успешного импорта проверьте состояние пула и список dataset:

zpool status -v
zfs list -r
zfs list -t snapshot

Команда zpool status показывает состояние пула, ошибки чтения и записи, а также статус каждого vdev и диска. Команда zfs list помогает понять, вернулась ли исходная иерархия dataset. Наличие старого имени пула без ожидаемых dataset не означает, что файлы доступны.

Если dataset видны, сначала скопируйте критичные файлы на другой носитель. Не удаляйте снапшоты, не меняйте свойства dataset и не запускайте очистку, пока не проверите содержимое и не получите отдельную копию.

Что делать, если импорт не удался

Сообщение об отсутствии пула или повреждении labels означает, что ZFS не может собрать исходную структуру штатными средствами. Это не доказывает, что каждый старый байт уже перезаписан, но закрывает обычный путь через zpool import.

Не повторяйте попытку с произвольными ключами. Не используйте на исходных дисках zpool create, zpool labelclear, zpool scrub и режимы импорта, которые откатывают транзакции. Ключ -F может отбросить последние транзакции при импорте и не подходит для экспериментов на единственном экземпляре данных.

Если резервной копии нет, зафиксируйте состояние дисков и работайте с побитовыми копиями, созданными на носители достаточного объема. Для критичных данных лучше передать копии в лабораторию восстановления. Утилита zdb может помочь с диагностикой отдельных структур, но она не превращает поврежденный или пересозданный пул в автоматически восстанавливаемую файловую систему. Практический разбор диагностики через zdb, scrub и resilver приведен в материале о восстановлении ZFS в TrueNAS и Proxmox.

Восстановление из резервной копии: основной путь

Отдельная резервная копия дает предсказуемый сценарий восстановления. Сначала создайте новый пул на проверенных дисках, затем восстановите dataset и только после проверки верните сервисы в рабочее состояние. Не используйте для нового пула диски, на которых еще может находиться единственная копия старых данных.

Резервная копия бывает потоковой, созданной через zfs send, или файловой, полученной копированием содержимого dataset. Потоковая копия лучше сохраняет структуру ZFS: снапшоты, дочерние dataset и часть свойств. Файловая копия возвращает файлы, но не исходную внутреннюю структуру ZFS.

Использование zfs send и zfs receive для восстановления

Поток zfs send содержит состояние dataset, зафиксированное снапшотом. Ключ -R передает dataset рекурсивно вместе с дочерними объектами и связанными снапшотами. Пример создания полной копии:

zfs send -R tank/data@full-2026-09-07 > /mnt/backup/data-full.zfs

Для приема потока на новый пул используйте отдельный dataset и отключите автоматическое монтирование до завершения проверки:

zfs receive -u newpool/data < /mnt/backup/data-full.zfs

Ключ -F нужен только в сценарии, когда приемник уже существует и его нужно откатить к состоянию потока. Он может удалить изменения и снапшоты, которых нет в резервной копии:

zfs receive -u -F newpool/data < /mnt/backup/data-full.zfs

На пустом целевом dataset этот ключ обычно не нужен. Перед его применением убедитесь, что на приемнике нет данных, которые требуется сохранить.

Инкрементальная копия передает изменения между двумя снапшотами. Сначала на приемнике должен существовать полный снапшот:

zfs send -R -i tank/data@full-2026-09-07 tank/data@inc-2026-09-08 > /mnt/backup/data-inc.zfs
zfs receive -u newpool/data < /mnt/backup/data-inc.zfs

После приема проверьте состояние пула, список снапшотов и доступность файлов:

zpool status -v newpool
zfs list -r -t all newpool
zfs mount newpool/data

Проверьте права, ACL, владельцев, квоты и работу приложений. Для базы данных одной проверки наличия файлов недостаточно: нужен согласованный дамп или штатная процедура проверки самой СУБД. Если резервная копия сделана до последнего снапшота, изменения после него в восстановленном пуле отсутствуют.

Восстановление из файловой резервной копии

При обычном копировании файлов сначала создайте dataset с нужными свойствами, затем перенесите содержимое с отдельного носителя. Для Linux-систем с поддержкой ACL и extended attributes часто используют:

rsync -aHAX --numeric-ids /mnt/backup/data/ /newpool/data/

Проверьте, что исходная файловая копия действительно содержит ACL, extended attributes, символьные ссылки и разреженные файлы. Параметры копирования зависят от ОС и инструмента, поэтому после переноса сравните число файлов, контрольные суммы выборки и права доступа.

Файловая копия не возвращает снапшоты, клоны, историю изменений, свойства исходного dataset, квоты и резервирования. Эти параметры придется настроить заново. Если структура dataset важна для приложений, зафиксируйте ее в отдельном описании конфигурации до восстановления.

Использование экспортированной конфигурации пула

Команда zpool export корректно отключает пул от системы и записывает состояние, необходимое для последующего импорта. Она не создает резервную копию пользовательских файлов и не сохраняет содержимое dataset в отдельный файл.

Перед изменением пула сохраняйте конфигурацию отдельно от самих дисков:

zpool status -v tank > /root/tank-zpool-status.txt
zpool status -g tank > /root/tank-zpool-guid-status.txt
zpool get all tank > /root/tank-zpool-properties.txt
zfs list -r -t all tank > /root/tank-datasets.txt
zfs get -r all tank > /root/tank-zfs-properties.txt
zpool history -il tank > /root/tank-history.txt

Вывод zpool status помогает восстановить схему mirror или RAIDZ, сопоставить устройства и проверить GUID. Сведения zfs list и zfs get описывают dataset, mountpoint, compression, recordsize, квоты и другие свойства. Файл с этими данными помогает собрать новый пул ближе к исходной конфигурации.

Если сохранен файл кэша пула, его можно передать команде импорта:

zpool import -c /path/to/zpool.cache

Путь и формат кэша зависят от платформы. Устаревший файл может содержать старые имена устройств и не заменить проверку фактического состава дисков.

Если пул был только экспортирован и его labels не повреждены, обычный импорт часто возвращает доступ к dataset:

zpool export tank
zpool import tank

Этот сценарий относится к штатному переносу пула. После zpool destroy и последующего zpool create сохраненный вывод не отменяет новые записи. Конфигурация описывает карту хранилища, а не сами блоки данных.

Когда восстановление невозможно: честная оценка

Результат зависит от трех факторов: состояния метаданных, объема новых записей и наличия отдельной копии. Таблица помогает быстро оценить сценарий.

Scrub проверяет контрольные суммы и исправляет поврежденные блоки, когда у пула есть рабочая избыточность mirror или RAIDZ. На одиночном диске scrub обнаружит проблему, но не возьмет правильный блок из другого устройства. Он не восстанавливает уничтоженные dataset и не отменяет перезапись.

Если импорт не работает, резервной копии нет, а на дисках уже создан и заполнен новый пул, штатных средств ZFS для возврата исходной структуры практически не остается. Специализированное восстановление иногда находит отдельные фрагменты, но результат не гарантирован и зависит от типа носителей, объема перезаписи и состояния labels.

Профилактика: как избежать потери данных в будущем

Настройка автоматического резервного копирования

Снапшоты защищают от случайного удаления и изменения файлов, но находятся в том же пуле. Отказ пула, удаление его labels или потеря нескольких дисков может сделать все локальные снапшоты недоступными.

Минимальная схема включает локальный снапшот для быстрых откатов и репликацию на отдельный хост или носитель:

zfs snapshot -r tank/data@daily-2026-09-07
zfs send -R tank/data@daily-2026-09-07 | ssh backup-host zfs receive -u backup/data

Для инкрементальной передачи используйте общий снапшот на источнике и приемнике:

zfs send -R -i tank/data@daily-2026-09-06 tank/data@daily-2026-09-07 | ssh backup-host zfs receive -u backup/data

Автоматизацию можно построить через cron, zfs-auto-snapshot или sanoid. Зафиксируйте срок хранения, например 7 ежедневных и 4 недельных копии, а для критичных данных храните несколько более старых точек восстановления. Удаление исходного снапшота до передачи инкремента разрывает цепочку репликации.

Резервная копия должна находиться на другом пуле, сервере или физическом носителе. Для отдельного принимающего сервера и временной инфраструктуры можно рассмотреть Timeweb Cloud, предварительно проверив объем диска, сетевую скорость, стоимость хранения и возможность регулярного приема потоков ZFS.

Раз в месяц выполняйте тестовое восстановление части данных. Проверяйте не только наличие файлов, но и права, ACL, снапшоты, работу приложений и согласованность баз данных. Резервная копия без проверки восстановления остается предположением о работоспособности.

Для контроля состояния пула используйте:

zpool status -v
zpool scrub tank
zpool list
zfs list

Scrub ищет повреждения до того, как они накопятся. Расписание зависит от нагрузки и размера пула, но его нужно закрепить как регулярную задачу мониторинга. Оставляйте свободными 20-30% емкости пула: заполнение до предела ухудшает стабильность производительности и уменьшает запас для обслуживания.

Практический порядок проверок после создания пула описан в руководстве по проверке и обслуживанию ZFS-пула. Список типичных ошибок при выборе vdev, работе со снапшотами и восстановлении собран в материале об ошибках при работе с пулом ZFS.

Экспорт конфигурации пула перед изменениями

Перед удалением, переносом или изменением пула сохраните сведения на отдельный носитель:

zpool status -v tank > /backup/tank-status.txt
zpool get all tank > /backup/tank-pool-properties.txt
zfs list -r -t all tank > /backup/tank-datasets.txt
zfs get -r all tank > /backup/tank-dataset-properties.txt
zpool history -il tank > /backup/tank-history.txt

Команду zpool export tank запускайте только когда нужно штатно отключить пул, перенести его на другой хост или подготовить диски к обслуживанию:

zpool export tank

Перед удалением проверьте имя каждого устройства, наличие актуальной резервной копии и успешность тестового восстановления. Конфигурацию храните вне пула вместе с описанием серийных номеров, схемы vdev, dataset, mountpoint, квот и расписания репликации.

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