Резервное копирование ZFS: как сочетать снапшоты и внешние бэкапы

Короткий ответ: снапшоты ZFS нужны для отката, внешний бэкап - для выживания после потери пула

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

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

Расписание выбирают через два показателя. RPO показывает допустимый объем потерянных изменений, а RTO - время, за которое сервис нужно вернуть в работу. Если допустима потеря максимум одного часа данных, снапшоты и передача на резервный сервер должны происходить чаще одного раза в час. Если сервис нужно восстановить за 30 минут, одной медленной копии в облаке недостаточно.

Рабочая минимальная схема для ZFS

1. Основной dataset, например tank/data, хранит рабочие файлы и приложения.
2. Автоматические снапшоты создаются каждый час, день и неделю по разным срокам хранения.
3. Снапшоты передаются на отдельный пул backup/data через zfs send/receive.
4. Копия критичных данных отправляется на другую площадку или в изолированное объектное хранилище.

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

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

Что именно защищает снапшот ZFS

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

Снапшот занимает место не сразу после создания. Расход растет по мере изменения и удаления блоков в исходном dataset. Если за сутки изменилось 200 ГБ данных, набор снапшотов может удерживать сопоставимый объем, даже когда сам dataset занимает несколько терабайт. Фактический расход зависит от характера записи, сжатия, удаления файлов и числа сохраненных точек.

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

Сценарии быстрого отката

Отдельный файл можно найти через каталог .zfs/snapshot, если просмотр снапшотов разрешен настройкой snapdir. Пример пути:

/tank/projects/.zfs/snapshot/before-deploy/docs/report.xlsx

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

zfs list -t snapshot -o name,creation,used,refer
test -f /tank/projects/.zfs/snapshot/before-deploy/docs/report.xlsx

Полный откат dataset применяют после неудачного обновления, массовой перезаписи или повреждения каталога. Команда выглядит так:

zfs rollback tank/projects@before-deploy

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

Снапшот подходит для таких ситуаций:

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

Ограничения локальных снапшотов

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

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

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

Общие свойства ZFS, влияние checksum, scrub, сжатия и структуры dataset описаны в обзоре возможностей и ограничений ZFS.

Чем внешний бэкап отличается от снапшота

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

zfs send/receive как основа репликации

zfs send преобразует состояние снапшота в поток, а zfs receive создает на целевой системе dataset и его снапшоты. Первая передача обычно полная. Следующие потоки содержат изменения между сохраненными точками.

Упрощенный пример первоначальной передачи:

zfs snapshot -r tank/data@base
zfs send -R tank/data@base | ssh backup-host zfs receive -u backup/data

Инкрементальная передача между двумя точками:

zfs snapshot -r tank/data@next
zfs send -R -I tank/data@base tank/data@next | ssh backup-host zfs receive -u backup/data

Ключ -I позволяет передать промежуточные снапшоты. Для иерархии dataset используют рекурсивный поток с -R. Ключ -w применяют для raw-передачи зашифрованных dataset, когда целевая система должна получить зашифрованные блоки без расшифровки на источнике. Конкретные ключи и поведение приема нужно сверять с версией OpenZFS или TrueNAS.

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

После каждой передачи проверьте:

• код завершения задания и журнал SSH или планировщика;
• наличие ожидаемого снапшота на целевой системе;
• возраст последней точки и размер принятого dataset;
• свободное место на целевом пуле;
• доступность ключей, если поток или dataset зашифрован.

Полный разбор параметров zfs send -R -I -w, автоматизации и обработки ошибок приведен в руководстве по репликации ZFS.

Когда нужны файлоориентированные или объектные бэкапы

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

Отдельный формат нужен для таких объектов:

• конфигурации серверов и приложений;
• дампы баз данных;
• IaC-репозитории и state-файлы;
• ключи, сертификаты и секреты;
• небольшие документы, которые нужно хранить годами;
• данные приложений с собственным механизмом экспорта.

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

Какие данные оставить в снапшотах, а какие обязательно вынести наружу

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

Данные, для которых снапшоты особенно эффективны

• Пользовательские каталоги. Почасовые точки позволяют вернуть документ после случайного удаления.
• Рабочие каталоги проектов. Снапшот перед деплоем или миграцией дает быстрый путь к исходному состоянию.
• Файловые dataset. Копирование отдельных файлов из снапшота быстрее полного восстановления.
• Временные версии. Короткое хранение точек помогает разбирать недавние ошибки без значительного расхода места.
• Данные перед массовыми изменениями. Ручной снапшот с понятным именем облегчает откат и аудит действий.

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

Данные, которые обязательно должны иметь внешний бэкап

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

Базовая архитектура: основной пул, локальная реплика и offsite-копия

Трехуровневая схема соответствует принципу 3-2-1: минимум три экземпляра данных, минимум два независимых типа носителей или системы хранения, минимум одна копия вне основной площадки. Смысл правила не в количестве галочек, а в разделении угроз.

Основной ZFS-пул

Production-пул хранит dataset, рабочие сервисы и локальные снапшоты. Для него задают quotas, отслеживают свободное место и регулярно выполняют scrub. Базовые команды контроля:

zpool status -v tank
zfs list -o name,used,avail,refer,mountpoint
zfs list -t snapshot -o name,creation,used,refer
zpool scrub tank

zpool status -v помогает увидеть состояние vdev и ошибки, zfs list показывает использование dataset и снапшотов, а scrub повторно проверяет блоки и checksum. Scrub не заменяет бэкап: он обнаруживает повреждение и помогает ZFS восстановить данные с другой копии в mirror или RAIDZ, но не возвращает удаленный файл и не спасает весь сервер.

Оставляйте рабочий запас свободного места. Точный размер зависит от нагрузки, но пул, который регулярно подходит к полному заполнению, требует пересмотра retention, квот или емкости.

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

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

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

На резервной стороне задают собственный retention. Удаление старой точки на источнике не должно автоматически убирать последнюю рабочую копию на цели без проверки цепочки и результата следующей передачи.

Удаленная площадка или объектное хранилище

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

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

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

Как выбрать расписание снапшотов и бэкапов

Начните с RPO. Запишите, сколько изменений допустимо потерять для каждого dataset. Затем определите RTO, то есть допустимую длительность простоя. После этого сопоставьте требования со скоростью записи, размером полного набора, пропускной способностью канала и свободным местом.

Если dataset меняется на 50 ГБ в час, а канал между серверами передает в среднем 100 Мбит/с, передача всего часа изменений в идеальных условиях займет примерно 67 минут. Сжатие может уменьшить поток, но планировать нужно по измеренной, а не теоретической скорости.

Пример расписания для рабочих файлов

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

Пример расписания для баз данных и сервисов

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

• Логический или физический бэкап базы выполняют с интервалом, который соответствует RPO, например каждые 15 минут для журналов и раз в сутки для полного бэкапа.
• Снапшот dataset создают после завершения согласованной процедуры или вместе с механизмом, который гарантирует корректное состояние приложения.
• На резервный сервер передают и dataset, и нужные журналы, например WAL или binlog.
• Еженедельно проверяют восстановление базы на отдельном хосте и выполняют контрольный запрос к данным.

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

Retention и контроль заполнения пула

Политику хранения разделяют на короткие частые точки, ежедневные копии и долгосрочные месячные версии. Например, можно оставить 24 часовые точки, 30 дневных и 12 месячных, если расчет использования места подтверждает такую схему.

Контролируйте объем dataset и снапшотов через zfs list, следите за процентом заполнения пула и настраивайте уведомления. Очистка должна учитывать инкрементальные зависимости. Базовую точку нельзя удалять, пока целевая система не получила новую независимую базу или следующая передача не подтверждена.

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

Практический порядок настройки и проверки схемы

Настройка начинается с описания данных и заканчивается тестовым восстановлением. Создать задачу репликации недостаточно: нужно проверить полученную копию, права доступа, retention и реальное время возврата сервиса.

Подготовка dataset и политики снапшотов

1. Составьте список dataset и укажите владельца каждого набора.
2. Отдельно выделите базы данных, конфигурации, секреты, виртуальные машины и обычные файлы.
3. Для каждого набора запишите RPO, RTO, срок хранения и способ восстановления.
4. Задайте единый формат имен, например hourly-2026-09-07-1400 или before-upgrade-2026-09-07.
5. Разделите автоматические точки и ручные снапшоты перед изменениями.
6. Определите, какие dataset передаются рекурсивно, а какие исключаются.

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

zfs snapshot tank/data@before-change
zfs list -t snapshot -o name,creation,used,refer
zfs get snapdir tank/data

Ручные снапшоты удаляйте после завершения работ только после проверки. Команда zfs destroy tank/data@before-change необратима для этой точки, поэтому имя и цель нужно перепроверить дважды.

Первичная и инкрементальная передача

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

zfs snapshot -r tank/data@replica-0001
zfs send -R tank/data@replica-0001 | ssh backup-host zfs receive -u backup/data

zfs snapshot -r tank/data@replica-0002
zfs send -R -I tank/data@replica-0001 tank/data@replica-0002 | ssh backup-host zfs receive -u backup/data

Параметр -u принимает dataset без автоматического монтирования на цели. Это снижает риск случайной публикации резервных данных через сетевые протоколы. Принудительные параметры приема, включая -F, применяйте только после проверки содержимого цели: они могут откатить ее состояние.

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

Тест восстановления из каждого уровня

Проверка должна подтверждать рабочее состояние, а не одно наличие файлов. Используйте отдельный тестовый dataset или хост, чтобы не повредить production.

1. Восстановите один документ из локального снапшота, сравните размер, владельца, ACL и содержимое.
2. Поднимите копию dataset с резервного пула и проверьте чтение нескольких каталогов.
3. Восстановите базу из согласованного дампа, примените журналы и выполните контрольные запросы.
4. Разверните конфигурацию сервиса из offsite-копии на чистой системе.
5. Измерьте время каждого шага, запишите ошибки, нужные ключи и действия оператора.

Тест проводите после изменения версии TrueNAS, OpenZFS, схемы шифрования, сетевого доступа или политики retention. Результат фиксируйте в коротком runbook: источник восстановления, команды, порядок запуска зависимостей, ответственный и фактический RTO.

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

Хранение всех копий в одном пуле

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

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

Отсутствие защиты от административной ошибки и шифровальщика

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

Исправление: используйте отдельные учетные записи, минимальные привилегии и ограничение направления репликации. Резервный сервер не должен быть доступен пользователям как обычная файловая шара. Для удаленной копии включите versioning и неизменяемое хранение, если это поддерживает платформа. Снапшот сам по себе не получает статус immutable-бэкапа.

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

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

Исправление: проверяйте журналы, код завершения, возраст последней копии, размер потока, свободное место и checksum-ошибки. Настройте уведомление, если реплика не обновлялась дольше допустимого RPO. Периодически открывайте файлы и выполняйте полное тестовое восстановление.

Неправильная защита баз данных и виртуальных машин

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

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

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

Итоговая проверка схемы защиты

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

• Для каждого dataset записаны RPO, RTO, срок хранения и способ восстановления.
• На основном ZFS-пуле работают снапшоты с контролем заполнения.
• Есть отдельный резервный пул или сервер с независимыми накопителями и учетными данными.
• Критичные данные передаются на удаленную площадку или в изолированное объектное хранилище.
• Базы данных копируются согласованным способом, а не только через файловый снапшот.
• Цепочки zfs send/receive проверяются по журналам, возрасту точек и коду завершения.
• Для offsite-копий настроены шифрование, versioning, ограничение удаления или object lock.
• На основном пуле регулярно выполняются zpool status и zpool scrub.
• Восстановление отдельного файла, dataset, базы и конфигурации тестируется по расписанию.
• Инструкция восстановления содержит команды, порядок запуска сервисов, ключи и фактическое время выполнения.

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