Резервное копирование для систем хранения: стратегия 3-2-1 и практические связки rsync, ZFS, Restic, BorgBackup

Правило 3-2-1 остаётся базой: три копии данных, два разных носителя, одна копия вне основной площадки. В 2026 году такой схемы мало. Шифровальщики и угнанные учётные записи атакуют в первую очередь резервные копии, подключённые к сети или доступные по тем же ключам, что и продакшен. Рабочая формула сегодня: 3-2-1-1-0, где четвёртая единица означает одну offline или immutable копию, а ноль означает ноль ошибок при проверке восстановления.

Минимальный набор для системы хранения: локальный пул ZFS со снапшотами, отдельный NAS с версионными копиями по rsync и offsite-репозиторий Restic или BorgBackup в S3-совместимом хранилище со включённым object lock. Такой комплект закрывает три сценария отказа: сбой диска или пула, шифрование рабочих данных и потерю площадки целиком. Дальше разобрано, как выбрать инструменты, как связать их в скрипты и как проверить, что данные действительно вернутся.

Что меняется в резервном копировании систем хранения в 2026 году

Три сдвига меняют требования к бэкапу на системах хранения. Объёмы на NAS и файловых серверах растут быстрее, чем бюджеты на диски, поэтому полная копия раз в сутки перестаёт укладываться в окно бэкапа. Offsite переезжает в S3-совместимые хранилища, где доступны object lock и жизненные циклы объектов. Требования к RPO и RTO ужесточаются: для файлового сервера среднего офиса RPO 24 часа и RTO 8 часов стали нормой, для баз данных это 1 час и 2 часа соответственно.

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

Почему классические 3-2-1 уже недостаточны

Три сценария, в которых классическая схема отказывает.

Первый: шифровальщик. Внешний USB-диск, подключённый к серверу постоянно, SMB-шара с бэкапами и iSCSI-LUN, смонтированный на хосте, шифруются вместе с рабочими данными за минуты. Копия физически существует, но восстановить из неё нечего.

Второй: компрометация учётной записи. Если бэкап-сервер доступен по тому же SSH-ключу, что лежит в CI, или по доменной учётке администратора, атакующий получает доступ к репозиторию и снапшотам. Он удаляет и копии, и источник. Схема 3-2-1 при этом формально соблюдена: три копии были, двух носителей хватало, offsite присутствовал.

Третий: человеческая ошибка. Команда zfs destroy -r по неверному датасету или удаление снапшотов скриптом с опечаткой в переменной стирает историю версий за месяцы. Останется только последняя копия, и то не всегда.

Immutable backup - это копия, которую нельзя изменить или удалить до истечения заданного срока. Технически это S3 Object Lock в режиме compliance (удаление блокируется даже владельцем аккаунта), WORM-хранилища или ZFS-снапшоты с hold. Air-gap - копия, физически отключённая от сети: лента в сейфе, съёмный диск, выключенный сервер. Оба механизма убирают у атакующего возможность дотянуться до бэкапа.

Как адаптировать правило 3-2-1 под современные требования

Формула 3-2-1-1-0 расшифровывается так: три копии данных, два разных типа носителей, одна копия offsite, одна копия offline или immutable, ноль ошибок при проверке восстановления. Ноль здесь не пожелание, а критерий приёмки: пока тестовое восстановление не прошло успешно, копии считаются непроверенными.

Пример рабочей схемы для файлового сервера на 20 ТБ:

• Копия 1: локальный пул ZFS с ежедневными снапшотами, хранение 14 дней.
• Копия 2: NAS в соседней стойке, версионные копии по rsync с hardlink-ами, retention 7 ежедневных, 4 недельных, 12 месячных.
• Копия 3: offsite-репозиторий Restic в S3-совместимом хранилище, object lock на 30 дней, шифрование на клиенте.
• Плюс: раз в квартал ленточная или дисковая копия, физически вынесенная с площадки.

Проверка восстановления идёт по расписанию: ежедневно автоматический check репозитория, ежемесячно восстановление каталога на тестовый стенд, ежеквартально полный прогон с замером RTO. Подробнее про выбор носителей и защиту от шифровальщиков: схема 3-2-1 для резервного копирования.

Как выбрать инструмент: rsync, ZFS send/recv, Restic или BorgBackup

Выбор определяется двумя вопросами: какие данные защищаем и кому доверяем хранилище. Файлы и каталоги удобнее отдавать rsync или BorgBackup, целые пулы ZFS - через send/recv, а бэкап в чужое облако логично строить на Restic.

Рекомендации по сценариям: rsync - для синхронизации файлов на NAS и версионных копий на диске; ZFS send/recv - для ZFS-пулов, когда нужны консистентные снапшоты без остановки сервисов; Restic - для шифрованного бэкапа в облако и контейнерных сред; BorgBackup - для дедуплицированного бэкапа на свой сервер. Инструменты комбинируют: снапшот ZFS даёт консистентность, rsync переносит данные, Restic хранит offsite-копию.

rsync: когда нужна простая и предсказуемая синхронизация

rsync хорош там, где нужен предсказуемый результат без установки агентов: копирование каталогов на NAS, перенос данных между серверами, версионные копии с экономией места через hardlink-и. Флаг --link-dest создаёт жёсткие ссылки на неизменённые файлы из предыдущей копии, поэтому 30 ежедневных версий занимают место, близкое к одной полной копии плюс дельта.

Пример версионной копии: rsync -aHAX --numeric-ids --delete --bwlimit=50M --link-dest=/srv/backup/daily.0 /data/ /srv/backup/daily.1/

Ключевой момент: без --link-dest, --backup и ротации rsync создаёт зеркало, а не бэкап. Удаление файла на источнике немедленно отражается на копии. Для файловых серверов на ZFS или TrueNAS стоит сравнить методы до настройки: выбор метода резервного копирования в TrueNAS.

ZFS send/recv: снапшоты и репликация на уровне пула

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

Базовый цикл: zfs snapshot tank/data@2026-09-11-0200, затем zfs send -i tank/data@2026-09-11-0000 tank/data@2026-09-11-0200 | ssh backup-server zfs recv -F backup/data. Инкремент передаёт только изменённые блоки. Флаг -w (raw) сохраняет шифрование ZFS при передаче, флаг -c отправляет уже сжатые блоки и экономит CPU на слабом канале.

Контроль целостности: zfs scrub еженедельно или ежемесячно проверяет контрольные суммы всех блоков и восстанавливает повреждённые данные из реплик. Ограничения: версии ZFS на источнике и приёмнике должны совпадать или приёмник должен быть новее, а место под снапшоты планируется заранее, иначе пул заполнится и запись встанет. Практика по ZFS, Btrfs и rsync собрана в материале про резервное копирование и восстановление данных в Linux.

Restic: шифрование, дедупликация и облако

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

Рабочий цикл: restic init --repo s3:s3.example.com/backups создаёт репозиторий; restic backup /etc /srv --exclude-caches добавляет данные; restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune применяет политику хранения и физически удаляет лишние данные; restic check --read-data-subset=10% проверяет целостность. Ограничение скорости задаётся флагом --limit-upload, например 20 МБ/с, чтобы не забить канал.

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

BorgBackup: дедупликация на локальном или удалённом сервере

BorgBackup дедуплицирует данные по чанкам, шифрует репозиторий и сжимает архивы (zstd, lz4). Типовой цикл: borg init --encryption=repokey-blake2 ssh://backup@nas/./repo создаёт репозиторий; borg create --stats --compression zstd,6 ::etc-2026-09-11 /etc /srv создаёт архив; borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 удаляет старые архивы; borg compact освобождает место.

Различие с Restic в модели доверия. Borg требует SSH-доступа и установленного Borg на сервере репозитория, а сервер должен быть доверенным: при его компрометации возможна потеря данных. Restic работает с хранилищем без серверной части и подходит для недоверенного облака. Критерий выбора простой: свой сервер и максимальная дедупликация - Borg; чужое объектное хранилище - Restic.

Готовые связки и скрипты для автоматизации бэкапа

Ниже три связки с расписаниями. Команды оформлены обычным текстом, скрипты стоит прогнать сначала на копии данных: опечатка в переменной с датасетом или каталогом обходится дорого. Дополнительные шаблоны для cron и systemd есть в подборке про резервное копирование сервера 2026.

Связка 1: rsync + ZFS-снапшоты для файлового сервера

Задача: файловый сервер на ZFS, ежедневные версионные копии на NAS без остановки сервисов.

Логика скрипта snapshot-rsync.sh: в начале set -euo pipefail, чтобы любая ошибка останавливала выполнение. Переменные: DATASET=tank/data, SNAP=auto-$(date +%Y-%m-%d), DEST=/mnt/nas/backup/daily.1, PREV=/mnt/nas/backup/daily.0.

1. zfs snapshot tank/data@auto-2026-09-11
2. Предыдущий каталог переименовывается или переносится: прошлый день становится daily.0, текущий - daily.1.
3. rsync -aHAX --numeric-ids --delete --bwlimit=50M --link-dest=/mnt/nas/backup/daily.0 /tank/data/.zfs/snapshot/auto-2026-09-11/ /mnt/nas/backup/daily.1/
4. Ротация: скрипт удаляет daily.7, переименовывает недельные и месячные копии по политике GFS.
5. zfs destroy tank/data@auto-дата недельной давности освобождает снапшоты старше политики.

Расписание: systemd timer ежедневно в 02:00 с параметром RandomizedDelaySec=300, чтобы бэкап не стартовал ровно в момент других задач. Ограничение канала: --bwlimit=50M. Политика хранения: 7 ежедневных, 4 недельных, 12 месячных копий. Снапшот монтируется через каталог .zfs/snapshot и доступен только для чтения, поэтому рабочие данные не блокируются.

Связка 2: ZFS send/recv для репликации пула на резервный сервер

Задача: консистентная реплика ZFS-пула на удалённый сервер каждые 6 часов.

Скрипт zfs-repl.sh: SNAP=repl-$(date +%Y-%m-%d-%H%M), PREV определяется как последний снапшот с префиксом repl- на источнике. Далее zfs snapshot tank/data@$SNAP и zfs send -i tank/data@$PREV tank/data@$SNAP | ssh backup zfs recv -F backup/data.

Чтобы цепочка инкрементов не рвалась при удалении снапшотов, используют закладки: zfs bookmark tank/data@$SNAP tank/data#repl-bookmark, а передачу делают через zfs send -i tank/data#repl-bookmark tank/data@$SNAP. Закладка переживает удаление снапшота.

Расписание: строка cron 0 */6 * * * /usr/local/bin/zfs-repl.sh. Проверка: zfs list -t snapshot на источнике и приёмнике, сверка имён последних снапшотов, контроль zfs list -t bookmark. Ограничения: версии ZFS на обоих серверах должны совпадать, а место под снапшоты контролируется отдельно, иначе пул заполнится и репликация встанет.

Связка 3: Restic + BorgBackup для контейнеров и виртуалок

Задача: защитить Docker-хосты и KVM-виртуалки с дедупликацией и шифрованием.

Для контейнеров: Restic в S3-совместимое хранилище. Тома бэкапятся напрямую, базы данных через дампы: mysqldump --single-transaction или pg_dump -Fc пишутся в файл, затем restic backup /var/lib/docker/volumes /srv/dumps. Пароль репозитория передаётся через переменную окружения RESTIC_PASSWORD_FILE, файл читается с правами 600. Расписание: ежедневно в 01:30, retention restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12.

Для виртуалок: BorgBackup с образами qcow2 на локальный репозиторий. Перед копированием образ согласованно фиксируется через qemu guest agent или снапшот LVM либо ZFS. Команда: borg create --stats --compression zstd,6 ::vm-2026-09-11 /var/lib/libvirt/images/vm1.qcow2. Расписание: еженедельно в воскресенье, retention borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12, затем borg compact.

Мониторинг обязателен. Restic возвращает код 1 при мелких ошибках и 3 при частично нечитаемых файлах, Borg возвращает 1 при предупреждениях и 2 при ошибках. Скрипт-обёртка сравнивает код возврата с нулём и отправляет алерт в почту или webhook. Для хранилища артефактов и registry рядом с контейнерами логика похожа, разбор есть в материале про резервное копирование хранилища артефактов.

Как проверить, что бэкап восстановится

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

Автоматическая проверка целостности репозиториев

Restic: restic check проверяет структуру репозитория, restic check --read-data-subset=10% дополнительно читает 10% данных и сверяет контрольные суммы. Полная проверка через --read-data читает весь репозиторий и может занимать часы.

Borg: borg check --verify-data читает и проверяет данные архивов, borg check без флага проверяет только метаданные. ZFS: zfs scrub сверяет контрольные суммы всех блоков пула и восстанавливает данные из реплик, если они есть.

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

Тестовое восстановление: пошаговый сценарий

1. Восстановить один каталог из Restic на отдельный тестовый сервер: restic restore latest --target /restore-test --include /srv/app.
2. Сверить содержимое с источником: rsync -n -c -r --out-format="%n" покажет различия по контрольным суммам, либо sha256sum по списку файлов.
3. Открыть базу данных из бэкапа: pg_restore или mysql на тестовом инстансе, затем проверка целостности (pg_amcheck, mysqlcheck).
4. Запустить сервис на тестовом стенде и проверить, что приложение отвечает и читает данные.
5. Замерить время от старта восстановления до работающего сервиса и сравнить с целевым RTO.
6. Зафиксировать результат в журнале: дата, что восстанавливали, сколько заняло, какие ошибки всплыли.

Требование безопасности: тестовое восстановление не должно затрагивать продакшен. Отдельный стенд, отдельные сетевые сегменты, учётные данные только на чтение репозитория. Если восстановление идёт из offsite-копии, заодно проверяется скорость скачивания из облака: она часто становится узким местом при RTO в 2 часа.

Типичные ошибки при настройке резервного копирования

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

Ошибки, которые ломают рабочую среду

rsync с --delete без предварительной проверки удаляет данные на приёмнике, а при ошибке в порядке аргументов может задеть и источник. Защита: сначала rsync -n в режиме dry-run, затем реальный запуск, и только потом автоматизация в cron.

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

Бэкап открытой базы данных копированием файлов даёт несогласованный набор страниц, который не запускается. Защита: логический дамп (mysqldump --single-transaction, pg_dump) или снапшот ZFS с предварительным переводом базы в согласованное состояние.

Неверные права после восстановления ломают запуск сервисов. Защита: флаги -aHAX и --numeric-ids при rsync, восстановление от root, проверка владельцев и ACL на тестовом стенде.

Тяжёлый бэкап в рабочее время забивает канал и диск. Защита: --bwlimit для rsync, --limit-upload для Restic, ionice и nice для процессов, ночное окно.

Ошибки, которые делают бэкап бесполезным

Отсутствие offsite-копии. Пожар, затопление или кража в стойке уничтожают локальные копии вместе с источником. Решение: offsite в S3-совместимом хранилище с object lock, например на облачной платформе вроде Timeweb Cloud, где объектное хранилище тарифицируется по факту использования.

Незашифрованный бэкап в облаке. Провайдер и любой, кто получит доступ к бакету, читает данные. Решение: шифрование на клиенте (Restic, BorgBackup), ключи хранятся только у вас.

Отсутствие retention. Репозиторий растёт бесконечно, пока не упрётся в лимит места. Решение: политика GFS (7 ежедневных, 4 недельных, 12 месячных) и регулярный prune.

Игнорирование кодов возврата скриптов. Бэкап падает месяцами, никто не замечает. Решение: проверка кода возврата, алерты, контроль времени последней успешной копии в мониторинге.

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

Бэкап на тот же диск или пул. Смерть диска убивает и данные, и копии. Решение: отдельный носитель, отдельный пул, отдельный сервер.

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

Схема растёт по этапам. Один сервер: снапшоты ZFS и rsync на внешний диск или NAS. Парк серверов: центральный NAS с версионными копиями, отдельный хост для Restic или Borg с репозиториями, мониторинг кодов возврата. Несколько площадок: offsite в S3 с immutable-бакетами, репликация ZFS между площадками, вторая независимая копия у другого провайдера.

Критерии, что пора менять схему: окно бэкапа перестаёт укладываться в ночь, свободное место на репозитории меньше 20% от полного объёма, целевой RTO не достигается на тестовом восстановлении, требования регулятора или заказчика предполагают хранение версий дольше года.

Аудит текущей схемы удобно проводить по чек-листу:

• Есть ли три копии данных на двух типах носителей.
• Есть ли offsite-копия и включён ли object lock или immutable-режим.
• Изолированы ли учётные данные бэкапа от продакшена.
• Настроена ли политика retention и контролируется ли рост репозитория.
• Проводится ли тестовое восстановление по расписанию и ведётся ли журнал.
• Отправляются ли алерты при сбое бэкапа и при ошибках проверки.

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