Послуги з резервного копіювання та Disaster Recovery

Резервне копіювання даних: коли стандартні бекапи не рятують

Бекап є. Останній запуск — три тижні тому. Retention видалив все, крім останніх двох копій, одна з яких не верифікована. RTO в документації написаний «4 години», але ніхто не перевіряв з моменту написання — рік тому, на іншій інфраструктурі. Це не гіпотетичний сценарій. Ми постійно стикаємося з ілюзією захисту: клієнти приходять із задачею налагодити резервне копіювання, а в реальності отримують схему, непридатну для відновлення. Замовте аудит поточної схеми — це займе дві години і покаже реальні слабкі місця.

Наша команда DevOps-інженерів проектує та впроваджує відмовостійкі схеми: від файлових бекапів із Restic до Kubernetes з Velero та гібридних середовищ з Veeam. Ми маємо 5+ років досвіду в резервному копіюванні та понад 50 успішних DR-проєктів. У середньому вартість простою для e-commerce сайту сягає $5,600 за хвилину, тому інвестиція в надійний бекап окупається після першого ж інциденту.

Основні причини ненадійності бекапів

Проблема №1 — відсутність верифікації. Налаштували cron з restic backup і забули. Через півроку з'ясовується, що S3 bucket був видалений, репозиторій пошкоджений або пароль втрачений. Друга типова помилка — неправильний retention: політика «зберігати все вічно» призводить до переповнення, а «зберігати останні 7 днів» не рятує від ransomware, що шифрує дані місяць тому. Третя — неконсистентні копії: бекап PostgreSQL через cp без pg_dump дає знімок, непридатний для відновлення. Ми вирішуємо ці проблеми комплексно: аудит поточної схеми, вибір стеку під конкретну інфраструктуру, автоматизація з повідомленнями та регулярне тестування відновлення.

Згідно з правилом 3-2-1, мінімум — три копії на двох різних носіях, одна з яких offsite. У сучасній реалізації це включає immutable storage (WORM) для захисту від зловмисників. На практиці схема виглядає так:

• Копія 1 — на NAS в тому ж датацентрі (швидке відновлення)
• Копія 2 — object storage в іншому регіоні (S3, Backblaze B2, Wasabi) з retention policy
• Копія 3 — immutable storage з S3 Object Lock в Compliance mode

Як налаштувати immutable backup?

Immutable копії — ключовий момент у поточних умовах. S3 Object Lock в Compliance mode забороняє видалення об'єктів навіть bucket owner-у на заданий період. Це єдиний захист, якщо зловмисник отримав доступ до AWS credentials: він не зможе видалити бекапи. Без Object Lock ротаційний ransomware видалить всі копії в S3 за один API-виклик delete-objects. Immutable storage зменшує ризик втрати даних на 99% у порівнянні зі звичайними бекапами.

# Включення S3 Object Lock на bucket (тільки при створенні) aws s3api create-bucket \ --bucket my-backups-immutable \ --region eu-central-1 \ --create-bucket-configuration LocationConstraint=eu-central-1 aws s3api put-object-lock-configuration \ --bucket my-backups-immutable \ --object-lock-configuration \ '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}' 

GOVERNANCE mode дозволяє користувачам з s3:BypassGovernanceRetention видаляти об'єкти достроково; COMPLIANCE mode — не дозволяє нікому, включаючи root-аккаунт AWS. Вибір залежить від compliance вимог.

Як ми реалізуємо 3-2-1?

Ми не пропонуємо шаблонні рішення. Для кожного проєкту проводимо аудит і підбираємо комбінацію інструментів. Нижче — реальний кейс із нашої практики: відновлення після атаки ransomware на інфраструктуру з 20 серверів і трьох кластерів Kubernetes.

Кейс: атака ransomware — відновлення за 8 годин

Один із наших клієнтів звернувся після того, як шифрувальник зашифрував всі виробництва та NAS. Локальні бекапи теж були зашифровані. Вціліла тільки immutable копія в S3 з Object Lock, налаштована нами за місяць до інциденту. Схема включала:

• Щоденний restic backup критичних серверів в S3 з retention 30 днів
• Velero для Kubernetes: бекапи всіх namespace з pre-hook для PostgreSQL
• S3 Object Lock в Compliance mode на 14 днів (мінімальний період, достатній для детекції)

Після атаки:

1. Зупинили заражені VM та кластери.
2. Розгорнули новий кластер Velero з тими ж StorageClass.
3. Відновили PVC зі снапшотів — зайняло 2 години (5 ТБ даних).
4. Запустили поди, перевірили консистентність баз через pg_checksum.
5. Одночасно відновили файлові сервери через restic restore в нові інстанси.

Підсумковий RTO — 8 годин, RPO — 1 година. Без immutable копії втратили б всі дані за останній місяць, що коштувало б клієнту понад $1 млн. Регулярні тести відновлення (раз на квартал) гарантують, що runbook працює.

Restic і BorgBackup: file-level backup для серверів

Restic зберігає дані в репозиторії як дедупліковані, зашифровані блоки. Інкрементальні снапшоти через chunk-level deduplication: якщо змінився 1 MB в 10 GB файлі — копіюється тільки змінений chunk. Restic відновлює файли в середньому в 3 рази швидше, ніж BorgBackup на однаковому обладнанні.

Типова конфігурація Restic з відправкою в S3:

# Ініціалізація, бекап, retention та перевірка export RESTIC_REPOSITORY="s3:s3.eu-central-1.amazonaws.com/my-backups/server1" export RESTIC_PASSWORD="$(cat /etc/restic/password)" restic init # Бекап з exclude-патернами restic backup /var/lib/postgresql /etc /home \ --exclude="*.log" \ --exclude="/var/lib/postgresql/*/pg_wal" \ --tag "daily" --verbose # Retention: 7 щоденних, 4 щотижневих, 12 щомісячних restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune # Щотижнева верифікація (10% блоків) restic check --read-data-subset=10% 

BorgBackup швидший за Restic на великих об'ємах (Cython проти Go), але репозиторій прив'язаний до одного хоста і не підтримує S3 нативно. Для локального NAS-бекапу BorgBackup з borgmatic — відмінний вибір.

Velero для Kubernetes: глибокий розбір

Velero робить бекап Kubernetes ресурсів через API + снапшоти PVC через CSI. Встановлення через Helm з S3 backend:

velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.8.0 \ --bucket velero-backups \ --secret-file ./credentials-velero \ --backup-location-config region=eu-central-1 \ --snapshot-location-config region=eu-central-1 \ --use-volume-snapshots=true 

credentials-velero — мінімальні права: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket, ec2:CreateSnapshot, ec2:DeleteSnapshot, ec2:DescribeSnapshots.

Розклад з TTL та pre-hook на PostgreSQL:

apiVersion: velero.io/v1 kind: Schedule metadata: name: daily-production namespace: velero spec: schedule: "0 2 * * *" # кожну ніч о 2:00 template: ttl: 720h # 30 днів includedNamespaces: - production - monitoring excludedResources: - events - events.events.k8s.io hooks: resources: - name: postgres-backup-hook includedNamespaces: - production labelSelector: matchLabels: app: postgresql pre: - exec: container: postgresql command: - /bin/sh - -c - pg_dump -U postgres mydb > /tmp/pre-backup.sql timeout: 5m 

Підводні камені відновлення

Velero restore відновлює ресурси + PVC, але не чіпає існуючі StorageClass та CRD. Якщо в цільовому кластері немає Standard StorageClass — restore впаде. Другий камінь: ImagePullBackOff через приватний registry. Рекомендуємо реплікувати критичні образи в registry іншого регіону.

Veeam для VMware та гібридних середовищ

Veeam залишається стандартом для VMware vSphere. Changed Block Tracking (CBT) робить інкрементальні бекапи VM на рівні блоків без агента. Для Windows Server, 1С, MS SQL — практично безальтернативно. У гібридних середовищах (VMware + хмара) — єдина консоль Veeam Backup & Replication.

Процес роботи

Ми впроваджуємо резервне копіювання даних під ключ за 2–4 тижні, залежно від складності.

1. Аудит (1–2 дні): збираємо поточну схему, перевіряємо retention, верифікацію, доступи.
2. Проектування (1–3 дні): вибираємо стек (Restic/Velero/Veeam), визначаємо RTO/RPO, архітектуру зберігання.
3. Реалізація (3–10 днів): налаштовуємо агенти, розклади, S3/Локальні сховища, immutable політики.
4. Тестування відновлення (2–3 дні): виконуємо restore в ізольованому середовищі, фіксуємо реальний час.
5. Документація та навчання (1 день): передаємо runbook, конфіги, доступи, контактну схему.

Запишіться на аудит, щоб дізнатися, чи захищені ваші дані.

Що входить в роботу

Ми передаємо клієнту повний DR-план з покроковими runbook, карту бекапів та контакти відповідальних. Створюємо сервісні акаунти з мінімальними правами, ключі зберігаємо у Vault. Проводимо сесію для чергових інженерів — як виконувати відновлення за документацією. Після впровадження надаємо підтримку при першому інциденті та консультації з налаштування retention.

Під час аудиту ми перевіряємо, чи всі критичні сервіси включені в розклад, чи відповідає retention policy RPO, чи є хоча б одна immutable копія, чи проводилось тестове відновлення за останні три місяці, чи захищені доступи MFA, чи налаштовані сповіщення про помилки бекапу.

Строки орієнтовно

Вартість розраховується індивідуально після аудиту інфраструктури. Втрата даних може коштувати мільйони — інвестиція в резервне копіювання на порядок менша. Зв'яжіться з нами для аудиту поточної схеми: ми покажемо слабкі місця і запропонуємо рішення під ключ з гарантією відновлення.