Стратегии резервного копирования 3-2-1 и 3-2-1-1-0: практическая реализация на ZFS, rsync, restic и borg

Три копии данных, два типа носителей и одна копия вне основной площадки: это правило 3-2-1. Расширенная схема 3-2-1-1-0 добавляет четвёртую копию, физически недоступную по сети, и требует подтверждать восстановлением, что копия рабочая. Для систем хранения на ZFS и TrueNAS это значит простую вещь: снапшоты и реплика остаются в работе, а от потери данных защищает отдельная цепочка резервных копий.

ZFS send/recv, rsync, restic и borg закрывают разные участки схемы. Первые два быстро возвращают данные рядом с источником, вторые два дают дедупликацию, шифрование и проверку целостности, поэтому на них строят offsite-копии. Ниже: определения бэкапа, снапшота и реплики с таблицей различий, разбор 3-2-1 и 3-2-1-1-0, готовые команды и расписания для четырёх инструментов, порядок проверки восстановления без остановки продакшена.

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

Бэкап, снапшот и реплика: в чём разница и почему их путают

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

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

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

Почему RAID и ZFS-снапшоты не заменяют бэкап

RAID закрывает отказ диска: массив переживает выход из строя накопителя и продолжает отдавать данные. Дальше начинается зона, где RAID бессилен. Ошибка администратора с rm -rf, неверный скрипт, испорченная миграция или шифровальщик мгновенно распространяются на все диски массива, потому что массив показывает одно логическое устройство. Контрольные суммы ZFS лечат битые блоки, но не логические ошибки: если файл перезаписан или удалён, целостность не поможет.

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

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

Репликация: отказоустойчивость, а не защита данных

Репликацию строят на zfs send/recv, rsync, DRBD или асинхронной репликации средствами приложения. Её задача - высокая доступность и короткое окно простоя: отказ основного узла переживают переключением на второй, плановое обслуживание проходит без остановки сервиса, а RPO измеряется минутами.

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

Реплику можно учитывать как одну из копий 3-2-1 при условии, что рядом есть независимый бэкап с версионированием и защитой от удаления. Одна реплика вместо бэкапа - классическая причина потерять данные полностью.

Стратегия 3-2-1: классика резервного копирования

Правило расшифровывается так: минимум три копии данных (одна основная и две резервные), два разных типа носителей, одна копия вне основной площадки. Каждое требование закрывает свой риск.

• Три копии: потеря одной копии не оставляет без данных, остаётся время разобраться.
• Два типа носителей: отказ конкретного класса оборудования или интерфейса не убивает все копии сразу. Жёсткий диск, лента и объектное хранилище ломаются и деградируют по-разному.
• Одна копия offsite: пожар, затопление, кража серверной, отключение площадки не затрагивают копию в другом месте.

Рабочий пример для офисной инфраструктуры: продакшен на сервере (копия 1), rsync на локальный NAS в соседней стойке (копия 2), restic в объектное хранилище (копия 3). Носители: жёсткие диски и облако. Offsite: облако. Домашний вариант на TrueNAS выглядит так: данные в пуле, копия на внешний USB-диск, копия в S3-совместимое хранилище или Backblaze B2, Wasabi.

Чего 3-2-1 не закрывает: ransomware и вредоносного администратора. Если все три копии доступны по сети с одного хоста и не защищены от удаления, шифровальщик доберётся до них за то же время, что и до источника. Это ограничение снимает расширенная схема. Как связать копии, репликацию и расчёт объёма, разобрано в материале про резервное копирование в системах хранения: стратегия, схемы и проверка восстановления.

Как считать копии и носители в 3-2-1

Копия - независимый набор данных, который восстанавливается без обращения к источнику. Носитель - физический или логический тип хранилища: жёсткий диск, SSD, лента, объектное хранилище. Считайте по этой логике:

• Копия 1: рабочие данные на сервере или в пуле.
• Копия 2: rsync или zfs send/recv на отдельный диск, NAS, второй пул, не связанный с первым.
• Копия 3: restic или borg в offsite-хранилище, желательно с версионированием и защитой от удаления.

Что не увеличивает число копий: снапшоты ZFS на том же пуле, RAID-массив, LVM-снапшоты на тех же дисках, реплика, читающая данные с того же сетевого доступа без изоляции. Типовая ошибка учёта: администратор считает копией набор снапшотов и реплику, получает в отчёте «три копии», а независимая копия остаётся одна.

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

Стратегия 3-2-1-1-0: защита от ransomware и человеческого фактора

Расширенная схема добавляет к 3-2-1 два условия. Первое: ещё одна копия (итого четыре) должна быть offline или immutable. Offline означает физически отключённый носитель, который подключают только на время бэкапа, то есть air gap. Immutable означает хранилище с политикой WORM, где объекты нельзя удалить или изменить до истечения срока хранения. Второе условие: ноль ошибок при проверке восстановления, подтверждённое регулярными тестами, а не успешным кодом завершения задания.

Offline и immutable копии: лента, внешний диск, S3 Object Lock

Вариант первый: лента LTO. Классический air gap, потому что картридж физически вынимается из библиотеки. Ленточная библиотека или отдельный привод стоит денег и требует регламента ротации, зато даёт срок жизни носителя в десятки лет и низкую стоимость гигабайта.

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

Вариант третий: облачные immutable-бакеты. S3 Object Lock в режиме compliance, аналогичный механизм в Backblaze B2 Object Lock и immutable-бакеты Wasabi не дают удалить объект раньше заданного срока, даже если у злоумышленника есть ключи доступа. Со стороны инструментов это выглядит так:

borg serve --append-only --restrict-to-path /srv/borg
restic -r s3:s3.example.com/bucket backup /srv/data

Режим append-only в borg не даёт удалять архивы по протоколу, а Object Lock страхует на уровне хранилища. Важная оговорка: immutable-бакет не спасает от потери ключей шифрования. Пароль restic, ключ репозитория borg, ключ пула ZFS храните отдельно от бэкапа: бумажная копия в сейфе, менеджер секретов с отдельной учётной записью, конверт в другом здании. Потеря ключа превращает идеальную копию в мусор.

Второй практический момент: immutable-копия не даёт мгновенно освободить место. Объекты живут до истечения срока блокировки, поэтому закладывайте рост хранилища заранее и учитывайте, что prune в restic не удалит заблокированные пакеты данных.

Ноль ошибок: что значит проверка восстановления

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

• restic check --read-data читает все пакеты данных из репозитория и сверяет контрольные суммы. Полная проверка дорогая по трафику, поэтому её планируют раз в месяц, а быстрый restic check - раз в неделю.
• borg check --verify-data проверяет архивы и читает данные, подтверждая целостность блоков.
• ZFS scrub читает пул целиком и сверяет контрольные суммы блоков. Для копий на ZFS это обязательная ежемесячная процедура.

Целостность репозитория - только половина дела. Вторая половина - восстановление файлов на отдельный стенд и сравнение контрольных сумм с источником. Метрики, на которые смотрят при тесте: RTO, то есть максимально допустимое время восстановления, и RPO, то есть максимально допустимая потеря данных по времени. Если RPO равен часу, бэкапы идут не реже раза в час; если RTO равен четырём часам, восстановление обязано укладываться в этот срок с учётом скорости дисков и канала.

Сравнение инструментов: ZFS, rsync, restic, borg

Инструменты сочетаются, а не конкурируют. ZFS-снапшоты дают мгновенный откат, zfs send/recv переносит точную копию файловой системы на второй пул, rsync делает зеркало файлов на NAS или внешний диск, restic и borg держат зашифрованные дедуплицированные репозитории для облака и долгого хранения. Подробный разбор связок с готовыми скриптами есть в статье про стратегию 3-2-1 и практические связки rsync, ZFS, Restic и BorgBackup.

ZFS: снапшоты и zfs send/recv для быстрых бэкапов

Снапшот создаётся мгновенно и не мешает работе. Дальше он отправляется на другой пул, локальный или удалённый по SSH:

zfs snapshot tank/data@auto-20260912
zfs send -i tank/data@auto-20260911 tank/data@auto-20260912 | ssh backup-host zfs recv backup/data
zfs send -w tank/data@auto-20260912 | ssh backup-host zfs recv backup/data

Флаг -i отправляет только изменения между снапшотами, поэтому ежедневная передача занимает минуты вместо часов. Флаг -w включает raw-режим и передаёт зашифрованный датасет без расшифровки на источнике, что важно при шифровании пула. Политику снапшотов удобнее держать в sanoid или zfs-auto-snapshot: типовой набор - 24 часовых, 7 ежедневных, 4 еженедельных, 12 ежемесячных. Еженедельная отправка на offsite-пул закрывает требование внешней копии, а второй пул не должен быть доступен на запись с основного сервера постоянно.

Скрипты, расписания и полный разбор связок ZFS, Btrfs и rsync для Linux собраны в руководстве по резервному копированию и восстановлению данных в Linux.

rsync: простое зеркалирование и инкрементальные копии

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

rsync -aHAX --numeric-ids --partial --delete --info=stats2 /srv/data/ /mnt/backup/data/

Расшифровка флагов: -a сохраняет права, время и символические ссылки, -H переносит жёсткие ссылки, -A и -X сохраняют ACL и расширенные атрибуты, --numeric-ids не ломает владельцев между разными системами, --partial позволяет докачивать большой файл после обрыва. Флаг --delete делает получателя точной копией источника, и в этом его опасность: если смонтировать пустой каталог вместо источника или перепутать аргументы, зеркало очистится.

Версионирование добавляется каталогом бэкапов:

rsync -aHAX --delete --backup --backup-dir=/mnt/backup/versions/2026-09-12 /srv/data/ /mnt/backup/data/

Удалённые файлы попадают в каталог с датой, откуда их можно вернуть. rsync не сжимает данные на хранении и не шифрует их, поэтому для облака его применяют редко: дедупликацию и шифрование берут на себя restic и borg. Типовое расписание: ежедневный rsync на локальный NAS, еженедельная копия на внешний диск, который после копирования отключается.

restic: дедупликация, шифрование и облачные бэкенды

restic шифрует данные на клиенте, режет их на блоки и дедуплицирует, поэтому повторные копии почти не занимают места. Репозиторий размещается в S3-совместимом хранилище, на SFTP-сервере или за REST-сервером. Для offsite-копии подойдёт объектное хранилище или отдельный сервер, например облачные ресурсы Timeweb Cloud, где можно держать как хранилище копий, так и промежуточный узел для отправки.

export RESTIC_REPOSITORY=s3:s3.example.com/backup-bucket
export RESTIC_PASSWORD_FILE=/etc/restic/pass
restic init
restic backup /srv/data --exclude-caches --tag daily
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check --read-data

Команда forget оставляет нужные точки восстановления по схеме GFS, prune удаляет неиспользуемые пакеты. Пароль хранится в файле с правами 600 и в отдельном месте вне сервера: без него репозиторий не открыть. Разумный минимум - две независимые копии пароля в разных физических местах.

borg: эффективная дедупликация и append-only репозитории

borg даёт дедупликацию, сжатие и шифрование, а append-only режим на стороне сервера закрывает репозиторий от удаления по протоколу. Схема с отдельным сервером копий:

export BORG_REPO=ssh://backup@backup-host/./repo
export BORG_PASSCOMMAND='cat /etc/borg/pass'
borg init --encryption=repokey-blake2
borg create --stats --compression zstd,10 ::data-2026-09-12 /srv/data
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12
borg check --verify-data

Режим repokey-blake2 хранит ключ в репозитории, что удобно, но требует резервной копии ключа: команда borg key export сохраняет его в файл, который убирают отдельно от сервера. Сервер копий запускает borg serve --append-only, и клиент физически не может удалить чужие архивы до истечения политики хранения.

Расписания и политики хранения: как не переполнить хранилище

Расписание отвечает на вопрос «как часто», политика хранения (retention policy) - на вопрос «как долго». Ошибка в любую сторону дорого стоит: слишком щедрая политика съедает диски, слишком скупая оставляет одну точку восстановления рядом с моментом аварии.

GFS и другие схемы retention policy

Схема GFS (grandfather-father-son) держит три уровня: ежедневные копии как сыновья, еженедельные как отцы, ежемесячные как деды. Рабочая конфигурация для среднего сервиса: 7 ежедневных, 4 еженедельных, 12 ежемесячных. Она даёт быстрый доступ к вчерашнему состоянию, откат на неделю назад и точку восстановления на каждый месяц года.

• ZFS: снапшоты ежечасно с хранением 24 штук, ежедневные с хранением 7, еженедельные с хранением 4, ежемесячные с хранением 12. Отправка на второй пул раз в неделю.
• rsync: ежедневное зеркало на NAS плюс каталог версий за 30 дней, еженедельная копия на внешний диск.
• restic: restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune в ежедневном задании.
• borg: borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12, отдельно от создания архива.

Альтернативы GFS для коротких циклов: keep-last для последних N копий, keep-hourly для баз данных с высокими требованиями к RPO, keep-within для хранения всего за период. Выбор зависит от RPO и от того, как быстро замечают порчу данных: если испорченный файл находят через две недели, политика на 7 дней бесполезна.

Автоматизация через systemd timers и cron

cron проще и есть везде, systemd timers надёжнее: умеют догонять пропущенные задания, вести журнал и разносить запуски по времени. Пример unit-файла:

[Unit]
Description=Restic backup
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/restic-backup.sh

[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=15m

[Install]
WantedBy=timers.target

Параметр Persistent=true запускает задание после включения сервера, если время старта было пропущено. RandomizedDelaySec разносит нагрузку, если бэкап идёт на один NAS с десятка серверов. Для cron строка выглядит так:

30 2 * * * flock -n /var/lock/backup.lock /usr/local/bin/backup.sh

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

Сколько места, времени и денег потребует схема

Считайте от объёма данных и суточного изменения. Для 2 ТБ данных с изменением 3% в сутки получается около 60 ГБ новых блоков ежедневно. Без дедупликации и сжатия годовая политика GFS накопит десятки терабайт, тогда как restic и borg за счёт дедупликации и сжатия обычно укладывают те же данные в несколько терабайт. Текстовые конфигурации и логи сжимаются в 3-5 раз, уже сжатые архивы и видео почти не сжимаются, дампы баз сжимаются умеренно.

Время передачи тоже считается: 1 ТБ по каналу 100 Мбит/с идёт около 22 часов, поэтому первичную копию в облако заливают заранее и с ограничением полосы, чтобы не забить рабочий трафик. Восстановление с жёсткого диска на 150 МБ/с даёт примерно 2 часа на терабайт, и этот срок входит в RTO. Стоимость облака зависит от тарифа и класса хранилища: immutable-хранение дороже обычного, лента дешевле на гигабайт, но требует привода или библиотеки. Тарифы меняются, поэтому перед выбором сверяйтесь с актуальными ценами провайдера.

Проверка восстановления и тестирование без простоя

Непроверенный бэкап не считается бэкапом. Тест восстановления нужен до инцидента, а не во время него, и проводить его можно, не останавливая продакшен.

Как провести restore drill на тестовом стенде

1. Выберите набор данных: каталог с конфигурациями, таблицу базы, произвольные 20-30 файлов из разных дат.
2. Восстановите копию на отдельную виртуальную машину или контейнер, не связанный с продакшеном.
3. Сравните контрольные суммы или запустите приложение на восстановленных данных. Для баз данных проверьте не только наличие файла, но и запуск СУБД.
4. Замерьте время от начала восстановления до готовности данных, это и есть фактический RTO.
5. Зафиксируйте результат в журнале: дата, инструмент, объём, время, ошибки. Журнал превращает разовые проверки в регулярный процесс.

Примеры команд для теста:

restic restore latest --target /mnt/restore --include /srv/data/critical
borg extract --list ssh://backup@backup-host/./repo::data-2026-09-12 srv/data/critical
zfs send backup/data@auto-20260912 | zfs recv testpool/restore

Для согласованности данных приложения используйте снапшот источника перед копированием: снапшот ZFS, LVM-снапшот или режим снимка в самой СУБД. Так файлы попадают в бэкап в одном состоянии, а не размазанными по времени записи. Проверку целостности репозитория совмещайте с тестом восстановления: restic check --read-data и borg check --verify-data подтверждают читаемость блоков, а восстановление на стенд - работоспособность процедуры. Готовые скрипты автотестов и варианты расписаний есть в материале про резервное копирование сервера и автотесты восстановления.

Метрики RTO и RPO: как их определить и проверить

RPO (Recovery Point Objective) - допустимая потеря данных по времени. RPO в один час означает, что копии создаются не реже раза в час, иначе между последней копией и аварией теряется больше допустимого. RTO (Recovery Time Objective) - допустимое время восстановления: от решения о восстановлении до работающего сервиса.

Метрики проверяются практикой. Если RTO заявлен в 4 часа, а тестовое восстановление 800 ГБ заняло 6 часов, план не выполняется, и решать это нужно заранее: добавить более быстрый носитель, держать локальную копию рядом с продакшеном, подготовить машину для восстановления и прогреть её. RPO проверяется по расписанию: посмотрите на последние три задания и убедитесь, что пропусков нет. Для баз данных с высокими требованиями к RPO ставят hourly-задания и отдельные проверки по журналам транзакций.

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

Типичные ошибки и чек-лист внедрения

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

• Нет offsite-копии: пожар или отключение площадки уничтожает все копии сразу.
• Все копии доступны по сети: ransomware шифрует их вместе с источником за минуты.
• Бэкапы не проверяются: восстановление обнаруживает битый репозиторий или неполные данные.
• Ключи шифрования и пароли хранятся рядом с бэкапом или только в голове администратора.
• Нет retention policy: хранилище переполняется, задания падают, и об этом никто не узнаёт.
• Снапшоты используются вместо бэкапа: пул теряется целиком вместе со снапшотами.
• Отсутствует мониторинг заданий: код выхода не проверяется, уведомления не настроены.
• Нет копии перед рискованными работами: миграция или обновление выполняется без свежей точки восстановления.
• Не документирована процедура восстановления: в момент аварии команды ищут в спешке.

Отдельный случай - хранилища артефактов: реестры контейнеров и репозитории пакетов требуют своей логики копирования и проверки. Разбор подходов есть в статье про резервное копирование хранилища артефактов.

Чек-лист для проверки стратегии резервного копирования

Пройдите по вопросам и отметьте ответы. Каждое «нет» - точка роста, а не повод отложить задачу.

1. Есть минимум три копии данных, и каждая восстанавливается без обращения к источнику?
2. Копии лежат на двух разных типах носителей, например диски и объектное хранилище?
3. Есть копия вне основной площадки, желательно с версионированием?
4. Есть копия offline или immutable: лента, выключенный внешний диск, бакет с Object Lock?
5. Проводилось ли восстановление за последние полгода, и уложилось ли оно в заявленный RTO?
6. Соответствует ли частота копий заданному RPO, нет ли пропущенных заданий?
7. Настроен ли мониторинг заданий с уведомлением при ошибке?
8. Хранятся ли ключи шифрования и пароли отдельно от бэкапов, в двух физических местах?
9. Закрыт ли доступ к репозиториям: append-only, отдельный сервер, ограниченные ключи?
10. Есть ли актуальная инструкция по восстановлению, которую сможет выполнить дежурный инженер?
11. Пересматривалась ли схема после изменения инфраструктуры или объёма данных?

Схема 3-2-1-1-0 снижает риск потери данных, но держится на дисциплине: расписания, мониторинг, проверки и отдельное хранение ключей. Начните с одного шага: восстановите один каталог из последней копии на тестовом хосте и замерьте время. Если факт не укладывается в RTO, меняйте схему сейчас, а не после инцидента.