Как восстановить данные из снапшота ZFS без отката всего датасета

Короткий ответ: восстановление файлов из снапшота ZFS без отката

Снапшот ZFS доступен только для чтения. Чтобы вернуть отдельный файл или каталог, не откатывая весь датасет, откройте снимок через каталог .zfs/snapshot в точке монтирования датасета и скопируйте нужные объекты обратно в рабочую область. Для одного файла используйте cp -a, для набора файлов или каталога - rsync с сохранением прав, владельцев, ACL и расширенных атрибутов. Сначала скопируйте данные во временный каталог, проверьте их, затем замените рабочую версию. Такой подход сохраняет все изменения, сделанные после создания снапшота, за исключением восстанавливаемого файла.

Пример: файл /pool/dataset/path/to/file удалён или повреждён. Снапшот pool/dataset@daily создан до ошибки. Восстановите файл командой:

cp -a /pool/dataset/.zfs/snapshot/daily/path/to/file /pool/dataset/path/to/file

Если каталог .zfs не виден, включите свойство snapdir=visible:

zfs set snapdir=visible pool/dataset

Для больших каталогов используйте rsync с предварительным просмотром изменений:

rsync -aHAXn --itemize-changes /pool/dataset/.zfs/snapshot/daily/path/to/dir/ /pool/dataset/path/to/dir/

После проверки выполните ту же команду без n. Важно: не применяйте zfs rollback, если нужно сохранить текущие изменения. Rollback откатывает весь датасет к состоянию снапшота и удаляет все последующие изменения.

Почему zfs rollback не подходит для выборочного восстановления

zfs rollback возвращает датасет к состоянию выбранного снапшота. Все изменения, сделанные после снимка, отменяются. Команда работает на уровне датасета, а не отдельных файлов. Если после снапшота были созданы другие снапшоты, zfs rollback потребует опцию -r для их удаления. Опция -R дополнительно удаляет клоны, созданные из более новых снапшотов. Это разрушительно для выборочного восстановления.

Что делает zfs rollback

Команда zfs rollback pool/dataset@snapshot откатывает датасет pool/dataset к состоянию на момент создания снапшота snapshot. Все файлы, созданные или изменённые после снимка, теряются. Удалённые после снимка файлы восстанавливаются. Если после указанного снапшота есть более новые снапшоты, ZFS откажется выполнять rollback без -r, так как это удалит и их. Опция -R также уничтожит клоны, созданные из этих снапшотов.

Можно ли выполнить zfs rollback без потери изменений

Без потери текущих данных выполнить rollback нельзя. Можно предварительно сохранить текущее состояние в новый снапшот: zfs snapshot pool/dataset@pre-rollback. Затем выполнить rollback. Если потребуется вернуться, откатитесь на pre-rollback. Но сам rollback всё равно изменит датасет целиком. Для восстановления одного файла этот метод избыточен и рискован.

Когда полный откат всё же оправдан

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

Как выбрать способ восстановления данных из ZFS snapshot

Выбор метода зависит от объёма данных, необходимости изоляции и доступных инструментов.

• Один файл: используйте прямой доступ через .zfs/snapshot и команду cp -a.
• Каталог или множество файлов: используйте rsync с dry-run для предварительного просмотра.
• Сложная проверка или работа с правами: создайте временный клон снапшота.
• Восстановление на другой пул или сервер: используйте zfs send/receive с последующим копированием.

Универсальность команды zfs mount для монтирования снапшотов зависит от платформы. В Linux и FreeBSD снапшоты можно монтировать, но в TrueNAS CORE/SCALE это может быть ограничено. Основной переносимый вариант - доступ через .zfs/snapshot или клон.

Прямой доступ через .zfs/snapshot

Каталог .zfs/snapshot автоматически присутствует в корне каждого датасета, если свойство snapdir установлено в visible (по умолчанию hidden). Внутри находятся подкаталоги с именами снапшотов, содержащие полное дерево датасета на момент снимка. Доступ только для чтения. Права пользователя могут ограничить просмотр или копирование, обычно требуются права root.

Временный клон снапшота

Клон создаётся командой zfs clone pool/dataset@snapshot pool/recovery. Он монтируется как отдельный датасет и доступен для чтения и записи. Изменения в клоне не влияют на исходный снапшот. Клон удобен для детального исследования содержимого или восстановления большого каталога. Клон использует copy-on-write: изначально не занимает дополнительного места, но по мере изменений потребляет пространство пула.

zfs send/receive для другого пула или сервера

zfs send передаёт поток данных снапшота, а не отдельный файл. Для выборочного восстановления примите поток во временный датасет на целевом пуле: zfs receive pool/recovery < snapshot.zfs. Затем скопируйте нужные файлы обычными инструментами. Этот метод подходит, когда исходный пул нестабилен или восстановление нужно выполнить на отдельном оборудовании.

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

Перед копированием определите точное имя датасета и снапшота, дату создания, точку монтирования и наличие дочерних датасетов. Выполните zfs list -t snapshot с выводом имени и времени. Проверьте zfs get mountpoint,snapdir. Сравните состояние через zfs diff. Для критичных данных создайте дополнительный снапшот текущего состояния перед заменой файлов.

Найти нужный снапшот по имени и времени

Команда zfs list -t snapshot -o name,creation,used,refer покажет все снапшоты пула. Выберите снимок, созданный до момента ошибки. Проверьте, что он содержит нужный датасет и путь. Автоматические снапшоты могут иметь похожие имена, обращайте внимание на дату создания.

Проверить mountpoint, snapdir и границы датасета

Узнайте точку монтирования датасета: zfs get mountpoint pool/dataset. Убедитесь, что свойство snapdir установлено в visible или используйте полный путь с .zfs/snapshot. Если нужный файл находится в дочернем датасете, снапшот родительского датасета его не содержит. Для дочернего датасета нужен отдельный снапшот.

Создать точку возврата перед заменой текущего файла

Создайте снапшот текущего состояния: zfs snapshot pool/dataset@before-restore. Для особо важных файлов дополнительно скопируйте текущую версию в отдельный каталог. Это позволит отменить восстановление, если выбран не тот снапшот или результат не устроит.

Как достать файл из снапшота ZFS через .zfs/snapshot

Основной сценарий для восстановления одного удалённого или перезаписанного файла.

Сделать снапшот доступным для просмотра

Если каталог .zfs не виден, выполните zfs set snapdir=visible pool/dataset. Проверьте: ls -la /pool/dataset/.zfs/snapshot. В Linux и FreeBSD поведение одинаковое, в TrueNAS CORE/SCALE доступ через SSH с правами root.

Скопировать один файл в безопасное временное место

Скопируйте файл во временный каталог: cp -a /pool/dataset/.zfs/snapshot/daily/path/to/file /var/tmp/zfs-restore/. Опция -a сохраняет владельца, права, временные метки. Проверьте размер, владельца и содержимое перед переносом в рабочий датасет.

Восстановить удалённый файл или заменить повреждённую версию

Для удалённого файла создайте отсутствующий каталог назначения и скопируйте объект. Для существующего файла сначала сохраните текущую версию, затем замените её проверенной копией из снапшота. Изменения в других файлах не затрагиваются.

Как восстановить каталог или набор файлов через rsync

Для больших каталогов используйте rsync с предварительным просмотром изменений.

Сначала выполнить dry-run

Команда rsync -aHAXn --itemize-changes /pool/dataset/.zfs/snapshot/daily/path/to/dir/ /pool/dataset/path/to/dir/ покажет список изменений без записи. Проверьте пути и направление копирования.

Сохранить права, владельцев и расширенные атрибуты

Ключи -aHAX сохраняют архивные атрибуты, hard links, ACL и расширенные атрибуты. --numeric-ids предотвращает преобразование UID/GID. Требуются права root. Для SMB/NFS проверьте соответствие UID/GID и ACL.

Не удалить актуальные файлы при синхронизации

Следите за завершающим слешем в источнике. source/ копирует содержимое каталога, source - сам каталог. Не используйте --delete, если не требуется полное приведение каталога к состоянию снапшота.

Клон снапшота и zfs send/receive для изолированного восстановления

Для больших каталогов, сложной проверки или восстановления на отдельный пул используйте клон или send/receive.

Когда клон удобнее прямого доступа к .zfs

Клон полезен при работе с большими каталогами, необходимости временно запускать утилиты на восстановленном дереве или когда требуется отдельная точка монтирования. Учитывайте требования к свободному месту и имени нового датасета.

Создать, смонтировать и проверить клон

Создайте клон: zfs clone pool/dataset@snapshot pool/recovery. Назначьте mountpoint: zfs set mountpoint=/mnt/recovery pool/recovery. Смонтируйте: zfs mount pool/recovery. Проверьте содержимое. Не путайте путь клона с рабочим датасетом.

Передать снапшот на другой пул или сервер

Используйте zfs send pool/dataset@snapshot | ssh user@host zfs receive pool/recovery. Учитывайте свойства, шифрование и совместимость версий OpenZFS. После приёма извлеките отдельные файлы через временный датасет.

Удалить временный клон только после проверки

После проверки восстановленных данных выполните zfs destroy pool/recovery. Убедитесь, что исходный снапшот не удалён. Перед удалением оцените зависимости клонов и расход места в пуле.

Проверка восстановленных файлов и сохранённых изменений

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

Сравнить содержимое и контрольные суммы

Сравните файл из .zfs/snapshot и восстановленную копию с помощью cmp или sha256sum. Для больших наборов используйте список контрольных сумм и выборочную проверку.

Проверить владельца, права, ACL и xattrs

Сравните stat, getfacl и getfattr для источника и назначения. Учтите UID/GID, SELinux-контексты, ACL SMB/NFS и особенности копирования между разными файловыми системами.

Проверить работу приложения

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

Ограничения: когда восстановление из снапшота ZFS не подойдёт

Снапшот хранится в том же пуле и не защищает от потери пула, массового повреждения носителей или удаления самого снапшота. Для защиты от отказа оборудования, ransomware или ошибки администратора нужны копии на другом пуле, сервере или носителе.

Снапшот не заменяет резервную копию

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

Файлы приложений могут быть логически несогласованными

Для баз данных и виртуальных дисков файловая копия может быть несогласованной. Используйте штатные средства резервного копирования приложений: quiesce, WAL/binlog, дампы.

Шифрование, права и дочерние датасеты

Для зашифрованного датасета загрузите ключ. Проверьте права root, ACL и соответствие UID/GID. Снапшот родительского датасета не содержит содержимое отдельно смонтированного дочернего датасета.

Недостаток свободного места и зависимости клонов

Проверьте zpool list, quotas и reservation. Клон использует copy-on-write и начинает занимать больше места по мере изменений. Удаление исходного снапшота может быть ограничено зависимостями.

Типовые ошибки при восстановлении из снапшота ZFS

Раздел в формате «ошибка - последствие - исправление».

Снапшот найден, но каталог .zfs не виден

Проверьте mountpoint и свойство snapdir. Не путайте скрытый каталог .zfs с отсутствующим снапшотом. При использовании TrueNAS учитывайте ограничения доступа через SMB/NFS и выполняйте операцию на хосте с административными правами.

Восстановление выполняется не из того датасета

Проверьте zfs list -r, точки монтирования и отдельные снапшоты дочерних датасетов. Сверьте абсолютный путь к исходному файлу с путём внутри снимка.

Текущий файл заменён без резервной копии

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

Rsync скопировал не то содержимое или удалил файлы

До запуска проверьте dry-run, source/ и target, не используйте --delete без необходимости. Для восстановления набора файлов ограничьте источник нужным каталогом или списком.

Файл восстановлен, но служба не может его использовать

Проверьте права от имени пользователя службы, владельца, ACL, xattrs и SELinux-контекст. Успешное завершение cp или rsync не гарантирует работоспособность приложения.

Краткий чек-лист: как восстановить файл из снимка без отката

1. Определите нужный датасет и снапшот.
2. Проверьте дату и путь.
3. Создайте снапшот текущего состояния.
4. Откройте .zfs/snapshot или создайте временный клон.
5. Скопируйте файл через cp -a или каталог через rsync с dry-run.
6. Проверьте содержимое, права и контрольные суммы.
7. Замените рабочую версию только после проверки.
8. Протестируйте службу.
9. Удалите временный клон только после подтверждения результата.

Помните: снапшоты не заменяют резервные копии на другом хранилище.