Услуги по резервному копированию и Disaster Recovery

Почему резервное копирование данных часто ненадёжно?

Бекап есть. Последний запуск — три недели назад. Retention удалил всё кроме последних двух копий, одна из которых не верифицирована. RTO в документации написан «4 часа», но никто не проверял с момента написания — год назад, на другой инфраструктуре. Это не гипотетический сценарий. Закажите аудит текущей схемы — это займёт два часа. Мы постоянно сталкиваемся с иллюзией защиты: клиенты приходят с задачей наладить резервное копирование, а в реальности получают схему, непригодную для восстановления. Наша команда DevOps-инженеров проектирует и внедряет отказоустойчивые схемы, от файловых бекапов до Kubernetes с Velero и гибридных сред с Veeam.

Почему большинство бекапов ненадёжны?

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

Согласно правилу 3-2-1 (Wikipedia), минимум, при котором одиночный отказ не уничтожает все копии — три копии на двух разных носителях, одна из которых offsite. В современной реализации это включает immutable storage для защиты от злоумышленников.

На практике схема выглядит так:

• Копия 1 — на NAS в том же датацентре (быстрое восстановление)
• Копия 2 — object storage в другом регионе (S3, Backblaze B2, Wasabi) с retention policy
• Копия 3 — immutable storage с WORM (Write Once Read Many)

Как настроить immutable backup?

Immutable копии — ключевой момент в текущих условиях. S3 Object Lock в Compliance mode запрещает удаление объектов даже bucket owner-у на заданный период. Это единственная защита, если злоумышленник получил доступ к AWS credentials: он не сможет удалить бекапы. Без Object Lock ротационный ransomware удалит все копии в S3 за один API-вызов delete-objects. Подробнее об immutable backup (Wikipedia).

# Включение 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}}}' 

According to AWS documentation, Object Lock in Compliance mode "prevents an object from being deleted or overwritten for a fixed amount of time".

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 копии потеряли бы все данные за последний месяц. Регулярные тесты восстановления (раз в квартал) гарантируют, что runbook работает.

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

Restic хранит данные в репозитории как дедуплицированные, зашифрованные блоки. Инкрементальные снапшоты через chunk-level deduplication: если изменился 1 MB в 10 GB файле — копируется только изменённый chunk.

Типичная конфигурация 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/Local хранилища, immutable политики.
4. Тестирование восстановления (2–3 дня): выполняем restore в изолированном окружении, фиксируем реальное время.
5. Документация и обучение (1 день): передаём runbook, конфиги, доступы, контактную схему.

Что входит в работу

• Документация: DR-план с пошаговыми runbook, карта бекапов, контакты ответственных.
• Доступы: создание сервисных аккаунтов с минимальными правами, хранение ключей в Vault.
• Обучение: сессия для дежурных инженеров — как выполнять восстановление по runbook.
• Поддержка: помощь при первом инциденте, консультации по настройке retention.

Чек-лист аудита бекапов:

• Все критичные сервисы включены в расписание?
• Retention policy соответствует RPO?
• Есть хотя бы одна immutable копия?
• Проводилось ли тестовое восстановление за последние 3 месяца?
• Доступы к бекапам защищены MFA?
• Есть уведомления об ошибках бекапа?

Сроки ориентировочно

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Потеря данных может обойтись в миллионы — инвестиция в резервное копирование на порядок меньше.

Получите консультацию инженера: свяжитесь с нами для аудита текущей схемы. Мы покажем слабые места и предложим решение под ключ с гарантией восстановления.