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

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

Целевая архитектура: как выглядит рабочий контур

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

flowchart LR
	A["Продуктив: ноутбук или сервер"] --> B["Копия 2: внешний диск или NAS"]
	A --> C["Копия 3: облако вне площадки"]
	B --> D["Проверка целостности и тест восстановления"]
	C --> D

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

Что означает каждая цифра

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

Два носителя или два устройства

Формулировку приписывают фотографу Питеру Крогу: он описал схему в книге «The DAM Book: Digital Asset Management for Photographers» (2005), а в широкий оборот её вывела публикация US-CERT «Data Backup Options» 2012 года. Тогда под «двумя носителями» понимали разные типы: жёсткий диск, оптический диск, лента, флеш-накопитель — защита от устаревания формата и от одновременного отказа однотипного оборудования.

Backblaze до сих пор формулирует пункт как «two different media», но прямо оговаривает: сегодня это значит не то же, что в конце 2000-х. Практический смысл сместился к двум разным устройствам — локальный диск и облако считаются двумя носителями, даже если под капотом у обоих те же HDD или SSD. Ноутбук, внешний SSD и объектное хранилище условию соответствуют.

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

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

Расширения: 3-2-1-1-0 и 4-3-2

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

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

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

Что закрывает этот сценарий:

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

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

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

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

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

# быстрый доступ к текущему состоянию
rsync -aH --delete /srv/data/ /mnt/backup/mirror/

# версионная локальная копия с историей снимков
restic -r /mnt/backup/restic-repo backup /srv/data --tag local

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

# параметры подключения храните в защищённом файле, а не в истории команд
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-backup-bucket"
export RESTIC_PASSWORD_FILE="/root/.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

4. Расписание

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

5. Проверка результата

Минимальный сценарий, который подтверждает работоспособность контура:

restic snapshots                       # в списке есть снимок за сегодня
restic check --read-data-subset=5%     # выборочная проверка целостности данных
# в общем репозитории добавьте --host и --path, иначе latest может указать на чужой снимок
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 завершается сообщением no errors were found, а diff не находит расхождений. Если проверка не выполняется, копия существует только на бумаге.

Восстановление важнее копирования

Бэкап оценивают не по факту наличия, а по времени и полноте возврата данных.

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

Антипаттерны

Выбор площадки для удалённой копии

При выборе удалённого хранилища проверьте четыре параметра: стоимость исходящего трафика при восстановлении, поддержку версионирования и Object Lock, лимиты на скорость выгрузки, а также юрисдикцию площадки. Если в копиях есть персональные данные граждан России, базы данных, в которые эти данные записываются и в которых хранятся, должны находиться на территории РФ (ч. 5 ст. 18 152-ФЗ). Требование распространяется и на резервные копии, а не только на продуктив.

Полезные ссылки

• Backblaze, разбор правила и его современной трактовки: backblaze.com/blog/the-3-2-1-backup-strategy
• Backblaze, сравнение 3-2-1, 3-2-1-1-0 и 4-3-2: backblaze.com/blog/whats-the-diff-3-2-1-vs-3-2-1-1-0-vs-4-3-2
• CISA, Data Backup Options (Carnegie Mellon, US-CERT, 2012) — публикация, закрепившая правило за Питером Крогом: cisa.gov
• Документация restic: restic.readthedocs.io
• Документация rsync: rsync.samba.org/documentation.html
• AWS S3 Object Lock: docs.aws.amazon.com

Утилиты из материала

Всё, что упоминается в командах выше, с официальными сайтами и исходным кодом.

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

• MEGA: полное руководство по надёжности, MEGAcmd и сценариям для Pro-аккаунта

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

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

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