Настройка offsite-бэкапов по правилу 3-2-1

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

Почему локальные бэкапы не спасают от ransomware

Типичная картина: rsync в ночь копирует данные с продакшн-сервера на NAS в той же серверной. Пожар, затопление машинного зала, ransomware, который шифрует сетевые шары — и основные данные, и «бэкап» исчезают одновременно.

Современные шифровальщики ждут 2–4 недели после заражения, прежде чем активироваться. За это время все инкрементальные бэкапы, смонтированные как сетевые диски, уже содержат зашифрованные файлы. Offsite-хранилище с immutable retention спасает именно в этом сценарии.

Как настроить immutable бэкап в облаке?

Immutable-хранилище имеет смысл только если туда нельзя записать поверх существующих данных и нельзя удалить раньше срока retention. Object Lock в Compliance mode от AWS S3 — это не опциональная фича, а обязательный параметр при настройке bucket.

# Создание S3 bucket с Object Lock
aws s3api create-bucket \
    --bucket company-offsite-backup \
    --region eu-central-1 \
    --create-bucket-configuration LocationConstraint=eu-central-1 \
    --object-lock-enabled-for-bucket

# Настройка retention по умолчанию
aws s3api put-object-lock-configuration \
    --bucket company-offsite-backup \
    --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
        "DefaultRetention": {
            "Mode": "COMPLIANCE",
            "Days": 30
        }
    }
}'

Это блокирует удаление объектов даже от root-аккаунта на 30 дней — именно то, что нужно при ransomware-атаке, когда злоумышленник получает доступ к AWS credentials.

Архитектура 3-2-1 на практике

Конкретная реализация зависит от объёма данных и RPO/RTO требований. Для большинства случаев рабочая схема выглядит так:

• Носитель 1 (локальный быстрый): бэкап на NAS или выделенный диск сервера — для быстрого восстановления отдельных файлов. Инструмент: Restic, Borgbackup или rsync с жёсткими ссылками.
• Носитель 2 (локальный медленный / tape): если объём позволяет, LTO-tape или второй NAS в другом здании или VLAN. Для небольших инфраструктур — второй диск того же сервера с другим физическим контроллером.
• Носитель 3 (offsite / облако): S3-совместимое хранилище — AWS S3, Backblaze B2, Wasabi, Minio в другом дата-центре, или выделенный сервер в другой локации. Это обязательная компонента схемы.

# Пример конфига Restic для offsite в S3
# /etc/restic/s3-backup.env
RESTIC_REPOSITORY=s3:s3.amazonaws.com/company-offsite-backup
RESTIC_PASSWORD_FILE=/etc/restic/password
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
AWS_DEFAULT_REGION=eu-central-1

#!/bin/bash
# /etc/cron.d/restic-offsite — ежедневный бэкап в облако
set -euo pipefail
source /etc/restic/s3-backup.env
restic backup \
  --files-from /etc/restic/include-paths.txt \
  --exclude-file /etc/restic/excludes.txt \
  --tag "daily,$(hostname)" \
  --compression max
# Политика хранения: 7 ежедневных, 4 еженедельных, 3 ежемесячных
restic forget --prune \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3

Что входит в настройку offsite-бэкапов под ключ?

Мы проектируем и внедряем полную схему 3-2-1 с учётом ваших RPO/RTO. В состав работ входят:

• Аудит текущей инфраструктуры и данных (сбор метрик, типов, объёмов).
• Выбор облачного провайдера и конфигурация bucket с Object Lock (AWS, Backblaze, Wasabi).
• Развёртывание агента (Restic/Borg) на всех целевых серверах, настройка политик хранения.
• Интеграция с мониторингом (Prometheus + Alertmanager или Grafana) — алерты при сбоях.
• Документирование процедуры восстановления runbook и обучение дежурной смены.
• Гарантия 30 дней на корректную работу схемы (бесплатные правки при необходимости).

Верификация и мониторинг

Бэкап без проверки — это не бэкап. Restic поддерживает restic check для проверки целостности репозитория и restic check --read-data-subset=10% для выборочного чтения данных. Это нужно запускать еженедельно, а не только после создания бэкапа.

Мониторинг размера, свежести и статуса последнего бэкапа должен быть интегрирован в Prometheus/Grafana или хотя бы в простую систему алертов. Если бэкап не выполнялся более 24 часов — алерт обязателен.

Сравнение инструментов для offsite-бэкапов

Restic в среднем на 30% быстрее в операциях бэкапа по сравнению с rsync с жёсткими ссылками при одинаковом объёме данных, благодаря встроенной дедупликации.

Процесс работы: от аудита до мониторинга

1. Аудит — определяем, какие данные критичны, их объём, текущие бэкапы, RPO/RTO.
2. Проектирование — выбираем носители, облачного провайдера, схему ротации.
3. Реализация — настраиваем агенты, политики, immutable storage, первый запуск.
4. Тестирование — проверяем восстановление случайной папки, измеряем скорость.
5. Деплой мониторинга — алерты, дашборды, оповещения в мессенджер/почту.

Ориентиры по срокам

Свяжитесь с нами для аудита вашей схемы бэкапов — оценим проект и предложим оптимальное решение. Закажите настройку offsite-бэкапов по правилу 3-2-1 и получите реальную защиту от потери данных.