Бэкап и аварийное восстановление для базы данных в десятки ТБ

Question

IT Interview Practice · Accepted Answer

**Сочетайте периодические снапшоты с непрерывным архивированием WAL для point-in-time recovery, реплицируйте offsite/cross-region и подтверждайте это регулярными учениями по восстановлению против явных целей RPO/RTO.** Бэкап, который вы никогда не восстанавливали, — это надежда, а не план.

## Архитектура

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## Как это работает

- **Снапшоты** — это полная копия тома/кластера (например, ежедневный EBS-снапшот или `pg_basebackup`). Это база, *с которой* вы восстанавливаетесь — но восстановление только до прошлой ночи теряет день записей.
- **Архивирование WAL / binlog** непрерывно стримит каждое изменение с последнего снапшота в объектное хранилище. Восстановление = снапшот + переигрывание WAL до любой выбранной секунды. Это **PITR (point-in-time recovery)** — восстановиться до 10:32:04, момента перед плохим `DELETE`.
- **Offsite / cross-region.** Бэкап в том же регионе, что и БД, умирает вместе с регионом. Реплицируйте во второй регион (S3 cross-region replication), чтобы региональный сбой или ransomware не забрали оба.
- **Учения по восстановлению.** Периодически восстанавливайтесь в тестовое окружение, измеряйте, сколько это заняло (**RTO**) и сколько данных вы бы потеряли (**RPO**), и сверяйте контрольные суммы с продом.

## RPO против RTO

- **RPO (Recovery Point Objective)** = сколько данных вы можете позволить себе потерять. Архивирование WAL каждые 5 мин → RPO ≈ 5 мин. Синхронная реплика → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = как быстро вы должны вернуться. Восстановление 20 ТБ из S3 может занять часы; тёплый standby-реплика сокращает RTO до минут.

## Взгляд с точки зрения интервью

Интервьюер прощупывает, знаете ли вы, что **одних снапшотов недостаточно** (потеря данных между ними), можете ли **определить RPO/RTO в числах** и **тестируете ли восстановления**. Отличные ответы подчёркивают, что непротестированные бэкапы отказывают ровно тогда, когда нужны, и выбирают стратегию из *бизнесового* RPO/RTO, а не из удобства. Ловушка: считать read-реплику бэкапом — репликация добросовестно копирует и `DROP TABLE`.

## Компромиссы и сбои

- **Стоимость против RTO.** Тёплый cross-region standby даёт минуты RTO, но удваивает инфраструктуру; холодное восстановление из S3 дёшево, но медленно. Покупайте уровень, который реально нужен бизнесу.
- **Нагрузка бэкапа.** Снапшот горячей БД на 20 ТБ добавляет I/O; делайте снапшоты с реплики.
- **Тихое повреждение (silent corruption).** WAL может заархивировать повреждённую страницу; периодическое полное восстановление + контрольная сумма ловит это.
- **Retention и комплаенс.** Держите достаточно истории (например, 35 дней PITR + месячные архивы) под юридические нужды; Glacier для дешёвого долгого хранения.
- **Когда не нужно:** крошечной БД достаточно ночного `pg_dump` в S3 — полный WAL + cross-region standby избыточны, пока потеря данных не измеряется реальными деньгами.

Архитектура

Как это работает

RPO против RTO

Взгляд с точки зрения интервью

Компромиссы и сбои

Похожие вопросы