Резервное копирование файлового архива: стратегия 3-2-1, инкрементальные бэкапы и проверка восстановления

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

Арифметика для архива на 10 ТБ простая. Полное копирование на скорости 200 МБ/с занимает около 14,5 часов и требует 10 ТБ свободного места на каждую точку. Ротация из 30 полных копий - это порядка 300 ТБ хранилища. Инкрементальная схема с жёсткими ссылками или ZFS send укладывается в объём базовой копии плюс ежедневные изменения, то есть часто в разы меньше.

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

Почему файловый архив - это отдельная задача резервного копирования

Файловый архив отличается от базы данных и набора конфигов по трем параметрам: объёму, характеру изменений и стоимости ошибки.

• Объём. Медиа, образы, дампы и документы измеряются терабайтами. Копирование такого объёма упирается в пропускную способность дисков и канала.
• Изменения. Ежедневно меняется небольшая доля файлов, остальное лежит неизменным месяцами. Ночной полный бэкап переписывает одни и те же байты.
• Целостность. Часть файлов не меняется годами, поэтому повреждение обнаруживается только при проверке контрольных сумм или при восстановлении.

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

Есть нюанс с дедупликацией. Крупные файлы (образы виртуальных машин, видео, ISO) плохо сжимаются, и выигрыш от дедупликации по блокам оказывается скромным. Экономию даёт не сжатие, а отказ от повторного копирования неизменённых данных.

Стратегия 3-2-1 для больших объёмов: как адаптировать под файловый архив

Классическое правило: не меньше трех копий данных, на двух разных типах носителей, одна из которых хранится вне основной площадки. Для больших архивов правило расширяется требованием к изоляции: offsite-копия не должна быть постоянно подключена к прод-сети. Вариации правила, включая 3-2-1-1-0, разобраны в материале Стратегии резервного копирования 3-2-1 и 3-2-1-1-0: практическая реализация на ZFS, rsync, restic и borg.

Рабочая конфигурация для архива на 10 ТБ выглядит так:

• Копия 1: рабочий датасет на сервере (ZFS-пул tank/data или обычная файловая система).
• Копия 2: локальный NAS, куда данные уезжают по rsync или zfs send через 10GbE.
• Копия 3: внешний HDD или лента, которую раз в месяц увозят в сейф, либо выгрузка в облако.

Три копии на одном диске ничего не защищают. Снапшот ZFS на том же пуле не спасёт от отказа пула и не переживёт rm -rf, если снапшоты удаляются по расписанию.

Выбор носителей для резервных копий больших архивов

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

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

Где размещать offsite-копию: облако, удалённый сервер или съёмный диск

• Облако (S3, Backblaze B2, Google Drive). Минимум администрирования и мгновенная доступность, но стоимость растёт вместе с объёмом, а восстановление ограничено каналом.
• Удалённый сервер или colocation. Вы контролируете железо и шифрование, платите за администрирование и аренду юнита.
• Съёмный диск в сейфе. Дешевле всего в расчёте на терабайт, требует ручных действий и дисциплины. Для архивов от 10 ТБ это часто основной вариант.

Пример ротации: два внешних диска по 12 ТБ, один подключён и обновляется, второй лежит в сейфе. Раз в месяц диски меняются местами, каждый хранит две-три последние полные копии.

Инкрементальные бэкапы и снапшоты: настройка rsync и ZFS

Настройка инкрементального бэкапа с rsync: команды и конфиги

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

rsync -aHAX --delete --numeric-ids \
  --link-dest=/backup/latest \
  /data/ /backup/2026-09-23/
ln -sfn /backup/2026-09-23 /backup/latest

Расшифровка ключей:

• -a - архивный режим: рекурсия, права, временные метки, симлинки, владельцы.
• -H - сохраняет жёсткие ссылки внутри источника, иначе структура ссылок развалится.
• -A и -X - ACL и расширенные атрибуты (xattr).
• --delete - удаляет в приёмнике файлы, которых больше нет в источнике, чтобы копия не превратилась в свалку.
• --numeric-ids - переносит числовые UID и GID, а не имена.

Скрипт с ротацией:

#!/usr/bin/env bash
set -euo pipefail

SRC=/data
ROOT=/backup
STAMP=$(date +%F)
DEST="$ROOT/$STAMP"

rsync -aHAX --delete --numeric-ids \
  --link-dest="$ROOT/latest" \
  "$SRC"/ "$DEST"/

ln -sfn "$DEST" "$ROOT/latest"

# удаляем каталоги старше 30 дней; место освободится,
# когда на файлы не останется других жёстких ссылок
find "$ROOT" -maxdepth 1 -mindepth 1 -type d -mtime +30 -exec rm -rf {} +

Первый запуск копирует весь объём, последующие занимают минуты или десятки минут. Узкое место для больших архивов - обход дерева: при миллионах файлов rsync тратит заметное время только на сравнение метаданных. Флаг --checksum заставит сравнивать содержимое, а не метаданные, и заметно замедлит работу, поэтому включайте его точечно. Если нужны версионность и дедупликация, смотрите на restic и borg: их связки с rsync и ZFS send разобраны в статье Резервное копирование для систем хранения: стратегия 3-2-1 и практические связки rsync, ZFS, Restic, BorgBackup.

Снапшоты ZFS и инкрементальная отправка: практический пример

zfs snapshot tank/data@2026-09-23
zfs list -t snapshot -o name,used,refer

Инкрементальная отправка на другой узел передаёт только изменения между двумя снапшотами:

zfs send -i tank/data@2026-09-22 tank/data@2026-09-23 \
  | ssh backup zfs receive backup/data

Полезные флаги: -p переносит свойства датасета, -R включает дочерние датасеты. Флаг -c (--compressed) формирует более компактный поток, используя сжатые WRITE-записи для блоков, которые сжаты на диске и в памяти; без этой опции данные распаковываются перед отправкой, чтобы их можно было разбить на меньшие размеры блоков. При приёме такого потока данные пересжимаются на стороне приёмника с использованием указанного алгоритма. Флаг -n у zfs receive означает «не выполнять приём потока фактически» (dry run): это удобный способ проверить поток без записи, в том числе чтобы убедиться в корректности имени, которое использовала бы операция приёма.

Для автоматизации подойдут sanoid или связка systemd timers со скриптом. Результат проверяется через zfs list -t snapshot на приёмнике. Снапшоты ускоряют инкрементальные копии и защищают от случайного удаления, но не заменяют offsite-копию: пул выходит из строя вместе со всеми своими снапшотами.

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

Ошибка в исключениях, сбой cron, забытый ключ шифрования, повреждённый сегмент ленты: всё это выясняется только при попытке развернуть данные. Две метрики, которые стоит измерять, - RPO (на какой момент времени восстановятся данные) и RTO (сколько времени займёт восстановление). Для архива 10 ТБ на скорости 200 МБ/с только перенос данных займёт около 14,5 часов, и это без распаковки и проверки хешей.

Как организовать регулярное тестовое восстановление

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

Результаты записывайте: дата, что восстанавливали, откуда, сколько заняло, что сломалось. Без записи тест через полгода превращается в ритуал без выводов. Схемы копирования и измерение реального RTO на стенде разобраны в статье Резервное копирование в системах хранения: стратегия, схемы и проверка восстановления.

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

Проверку удобно разделить на два уровня: контроль целостности самих копий и контроль восстанавливаемости.

# манифест хешей после бэкапа
cd /backup/latest && find . -type f -print0 \
  | xargs -0 sha256sum > /backup/latest.sha256

# проверка целостности пула ZFS
zfs scrub tank

# побайтовое сравнение файла с источником
cmp /data/archive/bigfile.tar /backup/latest/archive/bigfile.tar

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

Скрипт автотеста может восстанавливать файл в /tmp и сверять хеш с манифестом, а при расхождении отправлять уведомление. Готовые скрипты и порядок автотестов разобраны в материале Резервное копирование сервера 2026: стратегия, инструменты rsync, borg, rclone и автотесты восстановления.

Защита резервных копий от шифрования-вымогателя: изоляция и иммутабельность

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

Изоляция резервных копий: сеть, права, физическое разделение

• Сеть. Бэкап-сервер в отдельной подсети или VLAN. Соединение инициирует только он, прод-сервер не видит хранилище копий.
• Права. Отдельный пользователь для приёма копий, доступ строго на запись. Для ограничения SSH-ключа используйте утилиту rrsync: в authorized_keys приёмника ключу можно задать команду rrsync с каталогом, например command="rrsync /backup/incoming",no-pty,no-port-forwarding. Тогда по этому ключу нельзя выполнить произвольную команду. Учтите ограничение rrsync: на один authorized key может приходиться только один restricted dir.
• Физическое разделение. Съёмный диск, который лежит в сейфе и подключается только на время копирования, недоступен атакующему из сети.
• Облако. Отдельный аккаунт с MFA и ключами, которые не используются больше нигде.

Иммутабельные снапшоты и парольная защита архивов

Удержание снапшота защищает его от удаления: hold не даст уничтожить снапшот, пока его не снимут.

zfs hold keep tank/data@2026-09-01
zfs holds tank/data@2026-09-01
zfs release keep tank/data@2026-09-01

В облаке аналогичную роль выполняет S3 Object Lock: он помогает предотвратить удаление или перезапись объектов Amazon S3 в течение фиксированного, переменного или неопределённого времени по модели WORM. В режиме compliance защищённую версию объекта не может перезаписать или удалить ни один пользователь, включая root-пользователя аккаунта AWS; режим блокировки нельзя изменить, а срок хранения — сократить. Единственный способ удалить объект в режиме compliance до истечения срока хранения — удалить связанный аккаунт Amazon Web Services. Архивы на съёмных носителях имеет смысл шифровать:

tar -C /data -czf - . | gpg -c --cipher-algo AES256 > /mnt/vault/data-2026-09.tar.gz.gpg

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

Автоматизация и мониторинг бэкапов

Расписание проще держать в systemd timers: видно статус, есть журнал, пропущенные запуски отрабатывают после перезагрузки.

# /etc/systemd/system/archive-backup.service
[Unit]
Description=Backup file archive
OnFailure=notify-failure@%n.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/archive-backup.sh

# /etc/systemd/system/archive-backup.timer
[Unit]
Description=Run archive backup nightly

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

[Install]
WantedBy=timers.target

Включение: systemctl daemon-reload, затем systemctl enable --now archive-backup.timer. Журнал смотрите через journalctl -u archive-backup.service. Дальше настраивайте оповещения: unit OnFailure, письмо или сообщение в чат при ненулевом коде возврата, а также проверку свежести последней копии. Простое правило алерта - последний успешный бэкап старше 26 часов.

Минимальный набор сигналов на дашборде: время последнего успешного бэкапа, объём переданных данных, длительность, код возврата, свободное место на приёмнике и результат теста восстановления.

Готовые решения для бэкапов: пример Home Assistant Google Drive Backup

Не всё нужно писать руками. Дополнение Home Assistant Google Drive Backup создаёт копии Home Assistant по расписанию и автоматически выгружает их в Google Drive. Оно закрывает типовую проблему: локальные копии Home Assistant по умолчанию лежат на том же устройстве, где работает сама система, и при отказе диска или карты пропадают вместе с ней.

В интерфейсе дополнения есть частота создания копий (по умолчанию раз в три дня, можно переключить на ежедневную), лимит Max backups in Home Assistant для локальных и облачных копий, удаление локальной копии сразу после загрузки, пароль на архив и точное время запуска Backup time of day. Дополнение чистит старые копии локально и в Drive, чтобы не забить место, и уведомляет, если бэкапы отстали от расписания. Для его работы нужен Home Assistant OS или Supervised с магазином дополнений.

Логика та же, что и для больших архивов, только в меньшем масштабе: лимит копий подбирайте под свободный объём Google Drive. Каждый аккаунт Google включает до 15 ГБ хранилища, которое совместно используется Gmail, Google Drive и Google Photos. Если квота превышена 2 года или дольше и место не освобождают и не докупают, всё содержимое аккаунта Google может быть удалено, включая Gmail, Google Photos, Google Drive и резервную копию Android-устройства. Пароль на архив храните отдельно от аккаунта. Похожий приём применяют и в мобильных инструментах: приложение DSH сохраняет конфиги и плагины при обновлении по схеме бэкап, staged, swap и держит API-ключ в шифрованном хранилище.

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

Чек-лист регламента резервного копирования файлового архива

• Состав данных определён: какие каталоги, какие исключения, общий объём.
• Цели зафиксированы: RPO и RTO в часах, под них подобраны частота копий и скорость канала.
• Стратегия 3-2-1 выполнена: три копии, два типа носителей, одна вне площадки.
• Инкрементальные копии настроены: rsync с --link-dest или ZFS send, расписание в systemd или cron.
• Ротация задана: сколько копий хранить и через сколько удалять.
• Целостность проверяется: манифесты хешей, zfs scrub, контроль потока через zfs receive -n.
• Тестовые восстановления в календаре: еженедельно файл, ежемесячно каталог, ежеквартально полный стенд, ежегодно из offsite.
• Копии изолированы: отдельная подсеть, доступ на запись, ограниченный SSH-ключ, съёмный носитель в сейфе.
• Иммутабельность настроена: zfs hold, S3 Object Lock, парольная защита архивов.
• Мониторинг работает: алерты на код возврата и на последнюю копию старше 26 часов.
• Регламент документирован: кто отвечает, что делать при инциденте, где лежат пароли и ключи.

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