Налаштування 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 та отримайте реальний захист від втрати даних.