Резервное копирование СХД: стратегия 3-2-1, снапшоты, репликация ZFS и проверка восстановления

Почему снапшот - не бэкап, а репликация - не защита от всех угроз

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

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

Снапшоты ZFS: что они защищают и где бессильны

Снапшот ZFS фиксирует состояние датасета на выбранный момент. За счёт copy-on-write новые записи уходят в свободные блоки, а прежние остаются доступными по ссылке из снапшота. Создание занимает доли секунды и не зависит от объёма датасета. Место расходуется только на блоки, изменившиеся после создания точки.

zfs snapshot tank/data@2026-09-19-0200
zfs list -t snapshot -o name,used,refer,creation
zfs rollback tank/data@2026-09-19-0200

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

Второй момент, который часто упускают: снапшоты занимают место. Автобэкап без политики хранения упирается в квоту, и записи начинают падать. Задавайте retention заранее: например, 24 ежечасных, 14 ежедневных и 6 ежемесячных снапшотов на датасет.

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

zfs clone tank/data@2026-09-19-0200 tank/restore-20260919
mount -t zfs tank/restore-20260919 /mnt/restore

Репликация ZFS: когда она выручает, а когда создаёт ложное чувство безопасности

Репликация переносит датасет на другой узел: zfs send формирует поток, zfs receive применяет его на приёмнике. Копия лежит в отдельном пуле на отдельном железе, поэтому отказ основного сервера её не затрагивает. Восстановление укладывается в минуты: датасет уже развёрнут, остаётся переключить клиентов на приёмник.

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

Синхронная репликация даёт RPO около нуля, но чувствительна к задержке канала: каждая запись ждёт подтверждения от приёмника. Асинхронная работает по расписанию и допускает окно потери данных между инкрементами. Рабочий компромисс для СХД - асинхронная репликация каждые 5-15 минут.

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

Классический бэкап: чем отличается и почему без него не обойтись

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

Примеры: rsync на внешний диск, который отключают после копирования; zfs send на удалённый сервер с последующим zpool export; ленточная библиотека LTO с ротацией картриджей; объектное хранилище с immutable-политикой. Общее у всех вариантов одно: между продакшеном и копией есть разрыв, который ошибочный скрипт или злоумышленник не преодолеет за секунды.

Требование, которое нарушают чаще всего: бэкап должен быть недоступен для изменения из основной системы. Если копия смонтирована на том же сервере или открыта по SSH с правами записи, это вторая реплика со всеми её слабыми местами.

Стратегия 3-2-1 применительно к СХД: как адаптировать правило под реальную инфраструктуру

Правило 3-2-1 читается так: три копии данных, два разных типа носителей, одна копия вне офиса. Для системы хранения оно разворачивается в конкретную схему.

Три копии: рабочая СХД, реплика на втором узле, офлайн-копия. Два типа носителей: например, пул на HDD или NVMe и лента либо внешний диск. Одна копия вне офиса: удалённый ЦОД, облако или сейф в другом здании.

Каждый элемент закрывает свой сценарий. Рабочая СХД даёт доступ к данным, реплика спасает от отказа узла, офлайн-копия спасает от шифровальщика, ошибки администратора и пожара в стойке. Уберите любой элемент, и образуется дыра, которую рано или поздно вскроет инцидент.

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

Современное расширение 3-2-1-1-0 добавляет immutable или офлайн-копию и требование нуля ошибок при проверке восстановления. Готовые связки ZFS, rsync, restic и borg с расписаниями и retention policy разобраны в статье про стратегии 3-2-1 и 3-2-1-1-0 на ZFS, rsync, restic и borg.

Чек-лист для аудита текущей схемы:

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

Пошаговая настройка репликации ZFS-датасетов между узлами

Схема собирается из шести шагов: права на приёмнике, SSH-доступ, базовая передача, инкременты, автоматизация, контроль состояния. Синтаксис флагов проверяйте под свою версию OpenZFS: опции -i и -R стабильны давно, а поведение raw-потоков и resume может отличаться.

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

   zfs allow backup receive,create,mount,rollback,hold backup/data
   ssh-keygen -t ed25519 -f /root/.ssh/zfsrep
   ssh-copy-id -i /root/.ssh/zfsrep.pub backup@node2

2. Передайте базовую копию. Первый поток отправляет весь датасет и все вложенные наборы.

   zfs snapshot -R tank/data@base
   zfs send -R tank/data@base | ssh -i /root/.ssh/zfsrep backup@node2 zfs receive -u -d backup

3. Настройте инкременты. Каждый следующий поток несёт только изменения между двумя снапшотами.

   zfs snapshot tank/data@inc-2026-09-19-0215
   zfs send -i tank/data@base tank/data@inc-2026-09-19-0215 | ssh -i /root/.ssh/zfsrep backup@node2 zfs receive -u backup/data

4. Автоматизируйте. Запускайте скрипт по systemd timer или cron раз в 5-15 минут, задачу фиксируйте в логах.
5. Проверяйте состояние. На приёмнике должен появляться свежий снапшот, а поток данных - завершаться кодом 0.

   zfs list -t snapshot -o name,creation -r backup/data | tail
   zfs get -H -o value receive_resume_token backup/data

6. Учтите согласованность. Снапшот ZFS атомарен на уровне файловой системы, но не знает о состоянии приложения. Для PostgreSQL выполняйте pg_start_backup перед снапшотом, для MySQL - FLUSH TABLES WITH READ LOCK, для виртуальных машин - quiesce через гипервизор, иначе получите корректную ФС с несогласованной базой.

Пример скрипта для ежедневной репликации с автоматическим выбором последнего снапшота:

#!/bin/sh
set -eu
SRC=tank/data
DST=backup/data
REMOTE=backup@node2
STAMP=$(date +%Y-%m-%d-%H%M)
LAST=$(zfs list -H -t snapshot -o name -s creation -r "$SRC" | tail -n 1)

zfs snapshot "$SRC@$STAMP"

if [ -n "$LAST" ]; then
  zfs send -i "$LAST" "$SRC@$STAMP" | ssh -i /root/.ssh/zfsrep "$REMOTE" zfs receive -u "$DST"
else
  zfs send "$SRC@$STAMP" | ssh -i /root/.ssh/zfsrep "$REMOTE" zfs receive -u "$DST"
fi

Ручной скрипт хорош для понимания механики, но на длинной дистанции удобнее специализированные утилиты: sanoid с syncoid, zrepl, zfs-auto-snapshot. Они сами следят за цепочкой инкрементов, чистят старые точки и умеют уведомлять о сбоях.

Офлайн-копии: как сделать бэкап недоступным для атак и случайного удаления

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

Вариант 1, съёмный пул ZFS. Диск или набор дисков подключают по расписанию, принимают инкремент локально и выключают пул командой zpool export.

zpool create -o ashift=12 backuppool /dev/disk/by-id/usb-...
zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt backuppool/offsite
zfs send -i tank/data@prev tank/data@cur | zfs receive -u backuppool/offsite
zpool export backuppool

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

Вариант 2, append-only приёмник. SSH-ключ на источнике ограничивают forced command, чтобы он умел только принимать поток и не мог удалять датасеты и снапшоты на цели. В authorized_keys это выглядит так:

command="zfs receive -u backup/incoming",no-port-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAA... zfs-push

Вариант 3, лента. LTO с ротацией картриджей даёт настоящий офлайн: после записи носитель извлекают из библиотеки. Стоимость хранения на ленте ниже, чем на дисках, а срок жизни картриджа измеряется десятилетиями при правильных условиях.

Вариант 4, immutable-хранилище. Объектное хранилище с политикой WORM запрещает удаление и перезапись объекта до истечения срока хранения, даже для владельца учётной записи. Настройку методов защиты и сравнение репликации, rsync и облака для TrueNAS удобно смотреть в материале про выбор метода резервного копирования в TrueNAS: репликация, rsync или облако.

Отдельный приём для защиты от случайного zfs destroy: удержание снапшотов на приёмнике. Пока на снапшоте стоит hold, его нельзя уничтожить, в том числе рекурсивным удалением родительского датасета.

zfs hold keep backup/data@daily-2026-09-19

Hold не спасает от root, который сначала снимет удержание через zfs release. От осознанного злоумышленника защищает только офлайн-носитель или WORM-политика.

Проверка восстановления: как убедиться, что бэкап действительно работает

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

Методика из пяти шагов:

1. Выберите набор данных и сценарий: один файл, датасет, вся система хранения.
2. Разверните копию в изолированной среде, куда нет доступа из продакшена.
3. Сверьте содержимое: контрольные суммы, права, количество объектов, работоспособность приложения.
4. Замерьте время восстановления и сравните с целевым RTO.
5. Зафиксируйте результат в журнале: дата, что восстанавливали, сколько заняло, какие замечания.

Восстановление из снапшота без влияния на продакшен выполняется клоном и сравнением:

zfs clone tank/data@2026-09-19-0200 tank/verify-20260919
zfs diff tank/data@2026-09-19-0200 tank/data | head
find /mnt/verify -type f -exec sha256sum {} + | sort > /tmp/verify.sha256

Реплику проверяют приёмом в тестовый датасет, офлайн-копию - разворотом на отдельном стенде, где нет ни источника, ни доступа к его ключам:

zfs send -R backuppool/offsite@snap1 | zfs receive -u testpool/restore
zfs recv -u testpool/fromfile < /mnt/offline/data-full.zfs

Что проверять при каждом тесте:

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

Частота тестов зависит от цены простоя: для критичных систем - раз в месяц, для остальных - не реже раза в квартал. Целостность копий проверяют чаще и автоматически: zfs scrub раз в месяц, restic check и borg check раз в неделю, сверка контрольных сумм по расписанию. Регламент и автоматическую проверку восстановления без остановки продакшена описывает материал о встраивании бэкапов и снапшотов в систему качества хранения данных.

Типичные ошибки при резервном копировании СХД и как их избежать

1. Бэкап без проверки восстановления. Задача отработала, файлы на месте, восстановление не тестировалось. Решение: квартальный тест на изолированном стенде с записью результата и замером RTO.
2. Реплика с правами записи в той же сети. Шифровальщик шифрует источник и цель за один проход. Решение: приёмник только для чтения, forced command на источнике, отдельные учётные записи и сетевые сегменты.
3. Отсутствие мониторинга задач копирования. Бэкап молча падает три недели, узнаёте об этом на восстановлении. Решение: алерт на ненулевой код возврата и на отсутствие свежего снапшота на приёмнике.
4. Неверный retention. Слишком короткий срок удаляет нужную точку, слишком длинный забивает пул и останавливает записи. Решение: политика по уровням, ежечасные и ежедневные точки с ограничением по количеству плюс контроль свободного места.
5. Смешение снапшота и бэкапа. Единственная защита - снапшоты в том же пуле. Решение: добавить копию на другой носитель и офлайн-экземпляр.
6. Несогласованные снапшоты баз данных. Файлы целы, транзакции рассогласованы. Решение: скрипты подготовки и завершения перед созданием снапшота, проверка восстановлением СУБД.
7. Отсутствие шифрования копий. Утерянный диск с бэкапом раскрывает данные целиком. Решение: шифрование пула или архива, ключи отдельно от носителя.
8. Нет документации. О восстановлении знает один человек, который в отпуске. Решение: пошаговая инструкция, список ответственных, ежегодный пересмотр.

Инструменты и автоматизация для резервного копирования СХД

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

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

Как вписать резервное копирование в существующую инфраструктуру: RPO, RTO и документация

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

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

Специфика отдельных типов данных, например защита реестров образов и менеджеров артефактов, разобрана в материале про резервное копирование хранилища артефактов: стратегии, rsync, restic и TrueNAS. Общие практические связки rsync, ZFS send/recv, Restic и BorgBackup с готовыми скриптами и расписаниями собраны в руководстве по резервному копированию для систем хранения.

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