Ключевые выводы
- Резервное копирование клиентских данных — это не «бэкап раз в сутки», а стратегия с RPO, RTO, разными типами бэкапов и регулярными учениями восстановления
- Стандарт 3-2-1: 3 копии данных, на 2 разных типах носителей, 1 копия в географически удалённом месте
- Для CDP типовой паттерн: full backup раз в неделю + incremental ежедневно + WAL-archive в реальном времени
- Тестирование восстановления — обязательная часть стратегии: бэкап, который не тестировался, не работает
- В compliance-чувствительных проектах бэкапы должны быть зашифрованы и иметь свою retention-политику
Резервное копирование клиентских данных — задача, которой регулярно уделяют недостаточно внимания до первой потери данных. «У нас бэкапы делаются» — частая фраза CIO, после которой при инциденте выясняется, что бэкапы не тестировались, восстановление занимает 8 часов вместо 30 минут, или часть данных не покрывается.
Эта статья — практическое руководство по построению стратегии бэкапов для CDP-проекта в enterprise.
Базовые принципы
Правило 3-2-1
Стандарт индустрии: 3 копии данных (production + 2 backup), на 2 разных типах носителей (например, диск + объектное хранилище), 1 копия в географически удалённом месте.
RPO и RTO
- RPO (Recovery Point Objective) — допустимая потеря данных в минутах
- RTO (Recovery Time Objective) — допустимое время восстановления
Для CDP-проекта типовые цели: RPO 5-15 минут (потеря не более 15 минут данных), RTO 1-4 часа (восстановление за 4 часа).
Типы бэкапов
Full backup
Полная копия всех данных. Делается раз в неделю или раз в сутки. Самый медленный, но даёт быстрое восстановление.
Incremental backup
Только изменения с последнего бэкапа. Делается чаще (раз в час или раз в сутки). Быстрее, но восстановление требует применения цепочки инкрементов.
WAL-archive (для PostgreSQL)
Непрерывная архивация transaction log'а. Даёт point-in-time recovery с точностью до секунды. Это основа RPO ниже 5 минут.
Snapshot
Мгновенная фиксация состояния файловой системы или диска. Быстрая, но связана с конкретным storage-решением (LVM, ZFS, SAN snapshots).
Что включать в бэкап CDP
| Компонент | Тип бэкапа | Частота | Retention |
|---|---|---|---|
| Основная БД (PostgreSQL) | Full + WAL | Full раз/нед, WAL непрерывно | 30-90 дней |
| Аналитическая БД (ClickHouse) | Full | Раз/сут | 30 дней |
| Event store (Kafka) | Mirror + storage | Непрерывно | 30 дней |
| Конфигурации сервисов | Git + дамп | При изменении | Бесконечно |
| Файловое хранилище (templates, assets) | S3 versioning | Непрерывно | 1-2 года |
| Аудит-логи | Append-only архив | Непрерывно | 5+ лет |
Где хранить бэкапы
- Локально — для быстрого восстановления (на отдельных дисках или NAS)
- В удалённом ЦОД — для DR при катастрофах локального ЦОД
- В объектном хранилище — Yandex Object Storage, VK Cloud Storage, Selectel S3 для долговременного хранения
- На магнитных лентах — для очень долгого хранения (10+ лет) compliance-данных
Шифрование бэкапов
Для compliance-чувствительных проектов обязательно:
- Шифрование at-rest (AES-256)
- Управление ключами шифрования отдельно от бэкапов (KMS, HSM)
- Шифрование транзита при передаче в удалённое хранилище
- Регулярная ротация ключей
Без шифрования бэкап с ПДн в неправильных руках — это утечка с штрафом до 18 млн ₽.
Учения восстановления
Бэкап без проверки восстановлением — это файл на диске, не работающий бэкап. Стандарт enterprise:
- Раз в месяц — техническое восстановление одной БД на тестовой среде
- Раз в полгода — полное восстановление CDP в DR-площадке
- Раз в год — chaos-учения: симуляция потери продакшена, восстановление с нуля
Бюджет учений — 0.3-1 млн ₽ за подход. Окупается за один реальный инцидент, в котором команда уже знает алгоритм действий.
Точка-восстановления (PITR)
Возможность восстановиться на любой момент времени за последние N дней — это требование для критичных систем. Реализуется через:
- Регулярные base backups
- Непрерывная архивация WAL (для PostgreSQL)
- Возможность применить WAL до конкретной timestamp
PITR критичен для случаев, когда нарушение или ошибка обнаружена через несколько часов или дней — нужно вернуть систему в состояние «до проблемы», а не на ближайший суточный бэкап.
Право на забвение и бэкапы
При запросе субъекта на удаление данных бэкапы создают сложность: невозможно удалить данные субъекта из конкретного бэкапа без нарушения целостности. Стандартное решение:
- Retention бэкапов — 30-90 дней
- В этот период при восстановлении из бэкапа автоматически применяется журнал forget-запросов
- Долговременные архивы (3+ лет) либо обезличиваются, либо хранятся в формате с возможностью выборочного удаления
- В политике обработки явно указываем срок и порядок работы с бэкапами
Стоимость стратегии бэкапов
| Этап | Срок | Бюджет |
|---|---|---|
| Проектирование стратегии | 2-3 нед | 0.5-1 млн ₽ |
| Реализация и автоматизация | 4-6 нед | 1-2 млн ₽ |
| Storage инфраструктура | — | 0.5-2 млн ₽/год |
| Учения и поддержка | — | 0.3-0.8 млн ₽/год |
FAQ о резервном копировании
Какой минимальный набор бэкапов для CDP?
Для production: ежедневный full + WAL-archive (RPO 5-15 минут) с retention 30 дней. Это базовая страховка от типовых инцидентов: ошибки администратора, сбой железа, повреждение данных. Без этого минимума запуск CDP в production — это азартная игра.
Сколько занимает восстановление CDP полностью?
Зависит от объёма данных и архитектуры. Для базы 5 млн профилей со всеми связанными событиями — обычно 2-6 часов на полное восстановление с базы и WAL. С холодного бэкапа в облаке — добавьте время скачивания (1-3 часа в зависимости от объёма).
Можно ли использовать managed-сервисы для бэкапов?
Yandex Object Storage, VK Cloud Storage, Selectel S3 хорошо подходят для удалённого хранения бэкапов. Они закрывают вопросы географической удалённости, надёжности, шифрования. Стоимость — 1-3 ₽ за ГБ в месяц, что обычно дешевле собственной инфраструктуры.
Что делать с бэкапами при выводе из эксплуатации CDP?
Нужна стратегия завершения работы: какие бэкапы сохранить для compliance, какие можно удалить. Минимум — данные, удержание которых обязательно по закону (бухгалтерия, налоги), хранятся 5-7 лет. Остальные могут быть удалены вместе с системой, но процесс должен быть документирован.
Как тестировать процесс восстановления?
На отдельной test-среде с реальными бэкапами. Сценарий: «потеряли продакшен в N часов утра, нужно восстановиться к моменту времени T». Команда выполняет полный workflow восстановления и фиксирует время. Это даёт реалистичное RTO и выявляет проблемы в runbook'ах.
Что в итоге
Резервное копирование клиентских данных — это полноценная стратегия с RPO/RTO, разными типами бэкапов, шифрованием и учениями. Для CDP-проекта это не «бэкап на всякий случай», а критичная часть архитектуры на уровне с HA и monitoring.
Готовы помочь с проектированием стратегии бэкапов под ваш масштаб и compliance-требования — обсудим в формате архитектурной сессии.