Восстановление базы 1С после удаления Zvol в ZFS

Сначала сохраните всё, что ещё доступно средствами СУБД. Не перезапускайте сервер по кругу, не пересоздавайте массив и не запускайте zfs rollback. Резервную копию разворачивайте отдельно, а не поверх рабочей базы.

Если независимой копии нет, проверьте снимки ZFS. Подходящий снимок клонируйте в отдельное пространство. Полный откат вернёт весь dataset к прошлому состоянию и удалит более новые изменения.

Такая задача возникла после удаления Zvol примерно на 300 ГБ. Он находился в зеркальном ZFS-пуле из двух SSD Samsung 870 EVO по 2 ТБ. Один накопитель уже выпал из массива, второй содержал нечитаемые участки, а последняя резервная копия осталась с апреля.

Обычный анализ метаданных удалённый Zvol не нашёл. Дальнейшая работа потребовала разбирать сжатые блоки LZ4 и дерево объектов ZFS. Это рассказ о ходе восстановления, а не набор команд для экспериментов на боевом пуле.

Сначала выберите наименее рискованный источник данных

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

Zvol — блочный объект ZFS. Гипервизор или СУБД видит его как виртуальный диск. Удаление такого объекта лишает вас не отдельного файла, а целого блочного устройства со своей разметкой и данными.

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

FreeBSD Handbook советует извлекать данные из снимка в промежуточное место и проверять их до замены рабочих файлов. Для большого набора данных безопаснее создать клон в отдельном пространстве имён.

Список доступных снимков показывает команда:

zfs list -t snapshot

Команда только выводит перечень снимков. Она не подтверждает, что выбранный снимок содержит нужный Zvol и пригодную базу.

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

zfs rollback откатывает весь dataset

Команда zfs rollback возвращает dataset к состоянию выбранного снимка. Вместе с удалённым объектом она затрагивает все последующие изменения в этом dataset.

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

ZFS Recovery Cheatsheet Вадима Стасьева приводит такой синтаксис клонирования:

zfs clone pool/dataset@snapshot pool/recovery-clone

Имена пула, dataset и снимка замените своими. Не подключайте клон вместо рабочего тома, пока не проверите его содержимое.

Снимок ZFS фиксирует состояние файловой системы на момент создания. Для СУБД это crash-consistent копия: состояние похоже на результат внезапного отключения питания. После запуска база может потребовать журнального восстановления и собственной проверки целостности.

Снимок не заменяет внешний бэкап. Он живёт в том же пуле и зависит от тех же накопителей, контроллера и метаданных.

Штатный анализ не увидел удалённый Zvol

В статье «Восстановление данных с ZFS: задача со звёздочкой» стандартный анализ PC-3000 не обнаружил признаков удалённого Zvol. Другие сочетания Uberblock и Meta Object Set из кольца тоже не вернули объект.

Deadlists оказались пустыми. Поиск знакомого содержимого по регулярным выражениям дал мало результатов: пул использовал LZ4, а данные лежали фрагментированно.

Вывод: после удаления сжатого Zvol недостаточно искать заголовки файлов. Нужно восстанавливать структуру, которая связывала блоки виртуального диска.

У удалённого Zvol размер блока составлял 64 КБ. Параметр ashift=12 задавал минимальный шаг записи 4096 байт. Эти параметры относятся к конкретному пулу — переносить их на другую систему без проверки нельзя.

Первый анализатор пытался распаковывать данные с шагом 4 КБ. Такой перебор нагружал процессор и давал много ложных совпадений. Авторы разбора написали отдельный анализатор LZ4. Он рассчитывал ожидаемый размер распакованных данных и отбрасывал неподходящие блоки.

Здесь заканчивается обычное администрирование и начинается лабораторное восстановление. Команда импорта пула или файловый поисковик такую задачу не решают.

Вместо файлов пришлось собирать дерево Zvol

Следующий анализатор искал объекты Data Management Unit и косвенные блоки ZFS. В описанном пуле он выделил почти 33 млн DMU-объектов. Более 490 тысяч кандидатов относились к типам, которые специалисты связали с Zvol и его свойствами.

Эти номера типов нельзя использовать как универсальный справочник. Среди материалов нет документа разработчика ZFS с официальной расшифровкой. Здесь номера описывают только ход одного восстановления.

Известный объём виртуального диска помог отсеять свыше 95% кандидатов. Искомый Zvol занимал около 300 ГБ, поэтому структуры с другим размером исключили из дальнейшей проверки.

Оставшиеся кандидаты проверяли по связям между уровнями дерева. Анализатор проходил от DMU через уровни L3, L2 и L1 к первому блоку L0. Так удалось получить первые 64 КБ виртуального диска.

В этих данных появилась MBR и таблица разделов диска на 300 ГБ. Это подтвердило, что найденная цепочка описывает блочное устройство подходящего размера.

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

Первые найденные версии относились к нему. Специалисты различили варианты по номеру транзакции внутри исследуемой структуры. Предварительный объём нужных распакованных косвенных блоков превысил 300 ГБ.

Найденная MBR подтверждает структуру виртуального диска, но не исправность базы 1С. Между ними остаются раздел, файловая система, файлы СУБД и её внутренние страницы.

Извлечённую базу проверяют вне рабочей среды

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

Если внутри работала PostgreSQL, сначала сохраните полученный образ. Затем поднимите отдельный экземпляр совместимой версии СУБД и проведите журнальное восстановление. Подробный порядок описан в материале про возврат PostgreSQL к моменту перед сбоем.

Проверка не заканчивается успешным стартом службы. Откройте базу через клиент 1С, проверьте вход и чтение справочников. Затем проведите тестовый документ. Рабочий сервер при этом не трогайте.

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

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

Момент остановки важнее ещё одной попытки

Отсутствие Zvol в обычном анализе метаданных не доказывает, что все его блоки исчезли. В описанном случае часть структуры нашли после отдельного разбора LZ4, DMU и косвенных блоков.

Обратное тоже верно. Найденные фрагменты не гарантируют возврат всей базы. Результат зависит от сохранности блоков и состояния исходных накопителей.

Руководство illumos по восстановлению ZFS называет повреждение данных постоянным. Ремонт или замена накопителя не возвращает уже потерянное содержимое. Если повреждённые метаданные мешают открыть пул, основной путь — независимая резервная копия.

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

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

Если штатные способы не помогли

Передавайте накопители на структурное восстановление, когда независимой копии нет, подходящий снимок отсутствует, а метаданные не содержат удалённый Zvol. Приложите вывод zpool status, схему пула, известный размер Zvol и время удаления.

Срок и объём возврата заранее неизвестны. Оценить их можно после чтения накопителей и проверки сохранившихся структур. Если требуется разбор базы вместе с хранилищем и СУБД, оставьте заявку на диагностику аварийного контура 1С и SQL.

Порядок действий после удаления Zvol

1. Остановите запись в пул и не перезапускайте сервер повторно.
2. Сохраните доступную копию базы средствами СУБД.
3. Проверьте независимый бэкап и разверните его отдельно.
4. Получите список снимков командой zfs list -t snapshot.
5. Подходящий снимок клонируйте в другое пространство.
6. Не запускайте полный zfs rollback, пока не оцените более новые данные.
7. Если копии и снимка нет, снимите образы накопителей и остановите эксперименты.

Правило одно: удалённый Zvol сначала возвращают из независимой копии или клона снимка. Свободное пространство разбирают лишь тогда, когда оба пути закрыты.

Чтобы не повторилось

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

Проверяйте восстановление на отдельном сервере. Инструкция по резервному копированию базы 1С поможет связать расписание копий с регулярным тестовым развёртыванием.