Восстановление данных в TrueNAS: 3 рабочих сценария для сисадминов | Пошаговый гайд

Потеря данных - это критический инцидент для любого системного администратора или DevOps инженера. TrueNAS с файловой системой ZFS предоставляет несколько встроенных механизмов для быстрого и надежного восстановления. Эта статья - практическое руководство, которое поможет вам вернуть данные в трех ключевых сценариях: от случайного удаления файла до полного отказа системы. Вы получите проверенные пошаговые алгоритмы, команды для терминала и рекомендации по верификации результата, что позволит минимизировать время простоя и избежать необратимой потери информации.

Подготовка к восстановлению: что проверить перед началом

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

Выполните этот чек-лист, чтобы выбрать корректную стратегию:

Проверить наличие и актуальность ZFS снапшотов. Войдите в веб-интерфейс TrueNAS в раздел Storage -> Snapshots или выполните в Shell команду: zfs list -t snapshot -r pool_name/dataset_name. Убедитесь, что существуют снапшоты, созданные до момента потери данных. Обратите внимание на дату создания в имени снапшота (например, pool/dataset@auto-2026-04-28-1200).
Убедиться в работоспособности реплик. Если вы настраивали репликацию данных в TrueNAS, проверьте состояние задач в разделе Tasks -> Replication Tasks. Убедитесь, что последняя задача завершилась успешно и целевой пул доступен.
Найти архив конфигурации системы. Перейдите в System -> General. В разделе «Save Config» должна быть опция загрузки последнего сохраненного файла конфигурации (формат .db). Убедитесь, что у вас есть доступ к его копии, хранящейся вне основной системы (например, на локальном компьютере или в облаке).
Определить точный объем потери. Четко сформулируйте, что именно утрачено: несколько файлов в одном каталоге, целый датасет или вся система TrueNAS со всеми настройками. От этого зависит выбор одного из трех описанных ниже сценариев.

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

Сценарий 1: Восстановление удаленных или измененных файлов из ZFS снапшота

Это самый частый и наименее рискованный сценарий. Вы случайно удалили важный документ, перезаписали конфигурационный файл или столкнулись с повреждением данных в рамках одного каталога. ZFS снапшоты предоставляют мгновенный доступ к предыдущим версиям файлов через скрытую директорию .zfs/snapshot.

Как найти и просмотреть доступные ZFS снапшоты

Сначала определите, из какой точки восстановления вам нужны файлы. В веб-интерфейсе TrueNAS откройте Storage -> Snapshots. Таблица отобразит все снапшоты с именами, датами создания и занимаемым пространством. Отфильтруйте список по целевому пулу и датасету.

Альтернативно, используйте командную строку. Подключитесь к TrueNAS по SSH и выполните:

zfs list -t snapshot -r pool_name/dataset_name

Команда выведет список всех снапшотов для указанного датасета и его дочерних элементов. Имя снапшота имеет формат pool/dataset@snapshot_name. Запомните или скопируйте точное имя нужного вам снапшота.

Копирование файлов из снапшота: графический интерфейс и командная строка

Доступ к файлам в снапшоте можно получить двумя основными способами.

Способ 1: Через сетевой доступ (SMB/NFS). Если к датасету настроен общий доступ, просто перейдите в соответствующую сетевую папку с клиентского компьютера. Внутри вы увидите скрытую папку .zfs, а в ней - snapshot. Откройте папку с именем нужного снапшота и скопируйте из нее требуемые файлы в любое удобное место. Это самый простой метод для пользователей Windows или macOS.

Способ 2: Через Shell (командную строку). Этот метод универсален и не зависит от настроек сетевого доступа. Перейдите в корень смонтированного датасета и используйте команду cp.

# Восстановление одного файла
cp -rpv /mnt/pool/dataset/.zfs/snapshot/snap_name/path/to/file /mnt/pool/dataset/path/to/restore/

# Восстановление целого каталога
cp -rpv /mnt/pool/dataset/.zfs/snapshot/snap_name/path/to/folder/* /mnt/pool/dataset/path/to/restore/

Ключи -rpv означают рекурсивное копирование с сохранением атрибутов (прав, владельца, временных меток) и вывод подробной информации о процессе. После копирования обязательно проверьте права доступа (ls -la) и целостность восстановленных файлов.

Важное предупреждение: Не пытайтесь удалять или модифицировать файлы напрямую в директории .zfs/snapshot. Эта директория доступна только для чтения. Любые попытки записи приведут к ошибке. Альтернативный метод - использование команды zfs rollback, которая откатывает весь датасет к состоянию на момент создания снапшота. Помните, что rollback уничтожит все изменения, сделанные после этого снапшота, поэтому применяйте его с крайней осторожностью.

Сценарий 2: Полный откат датасета из ZFS реплики

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

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

Перед деструктивной операцией критически важно убедиться, что реплика актуальна и не повреждена. На целевом сервере (приемнике репликации) выполните команду для просмотра полученных снапшотов:

zfs list -t snapshot -r backup_pool/replicated_dataset

Сравните список и даты последних снапшотов с источником репликации. Они должны совпадать или быть максимально близкими по времени. Для дополнительной проверки целостности можно выполнить скрабинг пула реплики: zpool scrub backup_pool.

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

Если вы только планируете стратегию резервного копирования, детали настройки репликации описаны в практическом руководстве по Disaster Recovery в TrueNAS.

Пошаговый алгоритм отката датасета из реплики:

Остановите все службы, использующие целевой датасет. Отключите общие ресурсы SMB/NFS (Sharing), остановите виртуальные машины или контейнеры, которые хранят данные на этом датасете.
Создайте снапшот поврежденного датасета «на всякий случай». Это ваша последняя страховка перед удалением. Выполните: zfs snapshot pool/corrupted_dataset@before_recovery.
Уничтожьте поврежденный датасет. Выполните эту команду, только если уверены в актуальности реплики на 100%: zfs destroy -r pool/corrupted_dataset. Флаг -r рекурсивно удалит все дочерние элементы.
Восстановите датасет из потока репликации. На целевом сервере выполните получение последнего снапшота из источника. Команда может выглядеть так, если репликация настроена через SSH:
zfs receive -Fv pool/corrupted_dataset < ssh user@source_server "zfs send backup_pool/replicated_dataset@latest"
Ключ -F принудительно перезапишет целевой датасет. Ключ -v выведет подробный прогресс операции.
Пересоздайте общие ресурсы и запустите службы. После успешного получения данных верните настройки сетевого доступа, используя восстановленный датасет как источник.

Критическое предупреждение: Операция с ключом -F деструктивна для целевого датасета. Все данные, которые не были частью потока репликации, будут безвозвратно утеряны. Шаг 2 (создание снапшота) - обязательная мера предосторожности.

Сценарий 3: Аварийное восстановление всей системы TrueNAS

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

Импорт пулов данных после переустановки TrueNAS

После установки свежей версии TrueNAS на новое оборудование или очищенные диски первым делом необходимо импортировать существующие пулы с пользовательскими данными.

В веб-интерфейсе перейдите в System -> Storage и найдите кнопку Import Pool.
Система просканирует подключенные диски и предложит список обнаруженных пулов ZFS. Выберите нужный пул из списка.
Если пул был зашифрован, вам будет предложено ввести ключ шифрования или загрузить файл ключа.
Нажмите «Import». Система смонтирует пул и сделает его доступным.

Если пул не отображается в интерфейсе, используйте командную строку. Подключитесь по SSH и выполните zpool import. Команда выведет список всех обнаруженных, но не импортированных пулов. Для импорта выполните zpool import pool_name. После успешного импорта пул появится в веб-интерфейсе.

Восстановление конфигурации из архива: что восстанавливается, а что нет

Файл конфигурации TrueNAS (.db) - это спасение при аварийном восстановлении, но важно понимать его ограничения.

Что ВОССТАНАВЛИВАЕТСЯ из файла .db:

Все сетевые настройки (интерфейсы, IP-адреса, маршруты, DNS).
Пользователи, группы и их членство.
Конфигурации служб: SMB, NFS, iSCSI, FTP, S3.
Задачи по расписанию (Cron), задачи репликации и снапшотов.
Настройки виртуальных машин, контейнеров (jails) и их сетевые конфигурации.
Системные настройки (язык, время, оповещения).

Что НЕ ВОССТАНАВЛИВАЕТСЯ автоматически и требует ручных действий:

Пароли пользователей. Восстановятся имена пользователей, но не их пароли. Пароль пользователя root задается при загрузке конфигурации.
Сертификаты и ключи шифрования. Самоподписанные сертификаты TLS/SSL и ключи шифрования для пулов необходимо импортировать отдельно или пересоздать.
Данные плагинов, виртуальных машин и контейнеров. Конфигурация этих служб восстановится, но их данные (диски ВМ, тома контейнеров) должны храниться в импортированных пулах данных и будут автоматически связаны после восстановления конфигурации.

Процесс восстановления конфигурации прост: перейдите в System -> General, найдите раздел «Upload Config» и загрузите сохраненный файл .db. Система перезагрузится и применит все настройки.

Итоговый алгоритм аварийного восстановления системы:

Установите чистую версию TrueNAS (той же мажорной версии, что и была) на новое оборудование.
Импортируйте все пулы с пользовательскими данными через System -> Storage -> Import Pool.
Восстановите конфигурацию системы через System -> General -> Upload Config, загрузив архивный файл .db.
Перезагрузите систему и последовательно проверьте работу всех критических служб: сетевые интерфейсы, общие ресурсы (SMB, NFS, FTP), виртуальные машины, задачи репликации.

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

Верификация успешного восстановления и пост-операционные действия

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

Выполните этот универсальный чек-лист:

Проверьте контрольные суммы ключевых файлов. Для нескольких критически важных файлов (например, конфигов баз данных, архивов) сравните их хеш-суммы с известными эталонными значениями, если они есть. Используйте команду: sha256sum /path/to/recovered/file.
Убедитесь в доступности сетевых ресурсов. Попробуйте подключиться ко всем восстановленным общим папкам SMB/NFS с клиентских компьютеров. Проверьте чтение и запись тестовых файлов.
Проверьте работу запланированных задач. Зайдите в разделы Tasks -> Cron Jobs и Tasks -> Replication Tasks. Убедитесь, что задачи активны, их расписание корректно, а последние запуски прошли без ошибок.
Выполните тестовое чтение/запись. Запустите простой тест производительности в восстановленных датасетах, например, командой dd if=/dev/zero of=/mnt/pool/testfile bs=1M count=1024, а затем удалите тестовый файл. Это проверит не только доступность, но и стабильность работы пула.

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

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