Правило 3-2-1: рабочая схема резервного копирования

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

Целевая архитектура резервного копирования

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

flowchart LR
  A[Продуктив: ноутбук или сервер] --> B[Локальная версия: внешний диск или NAS]
  A --> C[Удалённая версия: хранилище вне площадки]
  B --> D[Проверка целостности и тест восстановления]
  C --> D

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

Что означают цифры 3-2-1

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

Чеклист быстрой проверки

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

Расширенные схемы 3-2-1-1-0 и 4-3-2

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

Неизменяемые копии и защита от шифровальщика

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

Защиту дают несколько независимых мер:

• Раздельные учётные данные. Агент резервного копирования получает минимально необходимые права для выполнения резервного копирования, но не права на удаление снимков и изменение настроек удержания. Удаление и ротацию выполняет отдельное административное задание с более привилегированным ключом. Команда restic forget --prune удаляет ненужные снимки и данные, поэтому доступ к ней нельзя оставлять у постоянно работающего агента без оценки риска.
• Append-only-репозиторий. Для собственного сервера можно использовать rest-server с режимом --append-only, чтобы клиент добавлял данные без обычной возможности удалять старые файлы.
• S3 Object Lock. Механизм работает в бакетах с включённым версионированием и защищает конкретные версии объектов от перезаписи или удаления в течение срока удержания. Чтобы новые версии действительно удерживались, задайте срок удержания на версиях объектов или настройте срок по умолчанию на бакете.
• Офлайн-копия. Внешний диск подключают только на время копирования, после чего физически отключают.
• Клиентское шифрование. restic шифрует содержимое до отправки в хранилище. Пароль репозитория хранят отдельно.

У S3 Object Lock есть два основных режима удержания:

• Governance защищает объект от большинства пользователей, но пользователь с разрешением s3:BypassGovernanceRetention может обойти ограничение, явно указав такой обход в запросе.
• Compliance запрещает сокращать срок удержания и удалять защищённую версию любому пользователю, включая root-пользователя AWS-аккаунта.

Эталонный сценарий с restic

Схема включает локальный версионный репозиторий на внешнем диске и удалённый репозиторий в S3-совместимом хранилище. Команды ниже сверены с интерфейсом restic 0.19.1 по переданной документации.

1. Локальная копия

Зеркало через rsync ускоряет доступ к текущим файлам. Историю изменений хранит локальный репозиторий restic.

# быстрое зеркало текущего состояния
rsync -aH --delete /srv/data/ /mnt/backup/mirror/

# инициализация локального репозитория: выполняется один раз
restic -r /mnt/backup/restic-repo init

# создание версионного снимка
restic -r /mnt/backup/restic-repo backup /srv/data --tag local

При автоматическом запуске задайте пароль через защищённый файл и ограничьте права доступа к нему. Один из поддерживаемых способов — переменная RESTIC_PASSWORD_FILE.

2. Удалённая копия

# задайте переменные окружения из защищённого файла или менеджера секретов
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-backup-bucket"
export RESTIC_PASSWORD_FILE="/secure/path/restic-password"
export AWS_ACCESS_KEY_ID="<access-key-id>"
export AWS_SECRET_ACCESS_KEY="<secret-access-key>"

restic init                       # выполняется один раз
restic backup /srv/data --tag daily

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

3. Политика хранения

# сохранить 7 дневных, 4 недельных и 12 месячных снимков
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Команда с --prune физически удаляет данные, которые больше не нужны сохранённым снимкам. В контуре с Object Lock или append-only удаляющее задание должно выполняться в отдельном административном процессе, совместимом с политикой удержания.

4. Расписание и контроль ошибок

# ежедневный запуск в 03:30 с записью журнала
30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Одного файла журнала недостаточно: настройте уведомление при ненулевом коде завершения. В restic 0.19.1 код 0 означает успех, 1 — фатальную ошибку без созданного снимка, а 3 при backup означает, что часть исходных данных не прочитана или исходный путь отсутствует и создан неполный снимок.

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

restic snapshots
restic check --read-data-subset=5%

# в общем репозитории ограничьте выбор нужным хостом и путём
restic restore latest --host "$(hostname)" --path /srv/data --target /tmp/restore-test

diff -r /srv/data /tmp/restore-test/srv/data && echo "restore OK"

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

Восстановление, RPO и RTO

Качество резервного копирования определяет фактический результат восстановления.

Зафиксируйте RPO и RTO для каждого набора данных. На квартальном тесте восстанавливайте реалистичный объём, проверяйте полноту файлов и измеряйте фактическое время. Тест пустого каталога не показывает, успеет ли система восстановить рабочий объём в установленный срок.

Антипаттерны резервного копирования

Выбор удалённого хранилища

Перед переносом данных проверьте:

• цену хранения и исходящего трафика при полном восстановлении;
• поддержку версионирования и Object Lock;
• ограничения скорости загрузки и выгрузки;
• доступные режимы удержания и права обхода Governance;
• регион хранения, юрисдикцию и договорные условия обработки данных;
• возможность восстановить весь объём в пределах RTO.

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

Официальные источники и документация

• CISA / US-CERT, Data Backup Options: cisa.gov
• Документация restic 0.19.1: restic.readthedocs.io
• Релизы restic: github.com/restic/restic/releases
• AWS S3 Object Lock: docs.aws.amazon.com
• Документация rsync: rsync.samba.org/documentation.html

Следующий шаг

Immich — self-hosted фото-библиотека вместо Google Photos

Связанные материалы

• Статья: Как мы перегоняем терабайт с Яндекс.Диска на Synology под присмотром Codex
• Блог: Данные важнее модели
• База знаний: TimeWeb, Selectel, Beget и Yandex Cloud — выбор VPS и развёртывание

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov