Базы данных
Backup и Recovery
GitLab в 2017 году потерял 300GB данных: случайный rm -rf на продакшн сервере. Проверили все backup стратегии: репликация (нет - удаление реплицировалось), S3 (нет - не настроен), локальный backup (нет - переполнен диск). Спас 6-часовой pg_dump. После: каждое изменение backup стратегии тестируется в staging.
- **GitLab**: RPO < 1 час, RTO < 4 часа; WAL-G в S3 + pg_basebackup каждую неделю
- **AWS RDS**: автоматический PITR до 35 дней, Multi-AZ для RTO < 1 минута
- **Stripe**: RPO < 1 минута, sync replication в 2 регионах для zero data loss при payment processing
Logical vs Physical Backup
Logical backup (pg_dump): выгружает данные как SQL или custom format. Переносимый между версиями и платформами. Медленно для больших БД (читает все данные). Physical backup (pg_basebackup, rsync data directory): копирует файлы БД напрямую. Быстро, но требует той же версии PostgreSQL и ОС.
pg_dump consistent: использует MVCC для consistent snapshot. Другие транзакции продолжают работать во время дампа. Нет блокировок на чтение. Но backup может пропустить данные записанные ПОСЛЕ начала дампа - это нормально, snapshot зафиксирован в момент начала.
Logical backup (pg_dump) занимает 3 часа. Приложение продолжало работать. Данные записанные через час после начала backup включены?
WAL Archiving
WAL (Write-Ahead Log) - журнал всех изменений в PostgreSQL. PostgreSQL сначала записывает изменение в WAL, потом применяет к данным (crash recovery). WAL archiving: копировать WAL файлы на внешнее хранилище по мере их создания. Вместе с base backup обеспечивает Point-In-Time Recovery (PITR).
WAL файл = 16MB по умолчанию. При 1GB/сек writes: 64 WAL файла в секунду = 5.5TB в день. Нужно настроить retention в S3: удалять WAL старше N дней. pgBackRest автоматически управляет retention и верификацией архива.
archive_command вернула ненулевой exit code. Что произойдёт с PostgreSQL?
Point-In-Time Recovery (PITR)
PITR позволяет восстановить БД на любой момент времени в прошлом: base backup + WAL до нужного момента. Сценарий: разработчик выполнил DROP TABLE в 14:30. Восстановление: база на 14:29. Потеряем только 1 минуту данных.
WAL-G (Wal-G) от Citus/Azure - наиболее популярный инструмент для WAL archiving и PITR в облаке. Поддерживает S3, GCS, Azure Blob. Параллельное сжатие LZ4/ZSTD, incremental backup через block-level deltas.
Для PITR минимально необходимо:
Disaster Recovery
Disaster Recovery (DR) - восстановление после катастрофического отказа (пожар в датацентре, регион AWS недоступен). В отличие от обычного failover, DR требует переключения на географически удалённую площадку. Уровни DR: active-passive (реплика в другом регионе), active-active (трафик в оба региона).
Chaos Engineering (Netflix Simian Army): намеренное выключение случайных компонентов в продакшне чтобы убедиться что система resilient. Chaos Monkey выключает EC2 инстансы. Chaos Kong выключает целый регион AWS. Если DR не тестируется регулярно - он не работает когда нужен.
DR standby в другом регионе. Primary упал. Как понять что standby актуален перед promotion?
RTO и RPO
RPO (Recovery Point Objective) - максимально допустимая потеря данных. "RPO = 1 час" означает: при катастрофе потеряем максимум 1 час данных. RTO (Recovery Time Objective) - максимально допустимое время восстановления. "RTO = 4 часа" означает: система должна быть восстановлена за 4 часа.
| Требование | Техническое решение | Стоимость |
|---|---|---|
| RPO = 0 (нет потери данных) | Sync replication (всегда дорого по latency) | Очень высокая |
| RPO < 5 мин | WAL archiving + streaming replication | Средняя |
| RPO < 24 часа | Ежедневный backup | Низкая |
| RTO < 30 сек | Active-active с automatic failover | Очень высокая |
| RTO < 4 часа | PITR из S3 | Средняя |
| RTO < 24 часа | Восстановление из ежедневного backup | Низкая |
SaaS SLA: Stripe требует RPO < 1 минута, RTO < 5 минут для payment processing. Это достигается через synchronous replication в 2+ регионах + automated failover. Стоимость: в 3-5x выше чем single-region setup.
Репликация = backup, если есть реплика - backup не нужен
Репликация реплицирует ВСЕ операции включая ошибки. DELETE продублируется на replica. Backup - snapshot исторических данных. Нужны оба для разных сценариев.
Классический инцидент: gitlab.com в 2017 удалил 300GB данных. Репликация не помогла - DELETE реплицировался. Единственное спасение - 6-часовой backup. Репликация = availability, backup = data protection.
Бизнес-требование: "потеря не более 1 часа транзакций при катастрофе". Что это - RTO или RPO?
Итоги
- **Logical vs Physical**: pg_dump переносимо но медленно; pg_basebackup быстро но требует той же версии
- **PITR**: base backup + непрерывный WAL архив = восстановление на любой момент; тестируй регулярно
- **RPO/RTO**: RPO = допустимая потеря данных, RTO = время восстановления; определяют архитектуру backup
Связанные темы
Backup тесно связан с репликацией и мониторингом:
- Репликация — Репликация = HA; backup = data protection. Нужны оба для разных failure сценариев
- Мониторинг — Мониторить: archive lag, backup size, backup duration, last successful backup
- Миграции — Перед рискованной migration всегда backup - checkpoint для rollback
Вопросы для размышления
- Как автоматизировать тестирование backup восстановления? (не "сделал backup = готово")
- Компания требует RPO=0. Какая архитектура нужна и какой ценой?
- Когда pg_dump предпочтительнее WAL-G + pg_basebackup несмотря на скорость?