← [Раздел](README.md) · [Главная](../README.md)

# Резервирование и аварийное восстановление (DR)

## Цель

Разобрать **резервное копирование**, репликацию данных и **планы disaster recovery (DR)**: RTO/RPO на практике, схемы active-passive и active-active, и как не попасть в ловушку «бэкапы есть, восстановить никто не умеет».

## Предварительно

- [Отказоустойчивость](otkazoustojchivost.md)
- Понимание primary/replica для БД

## Время

~75 минут

---

## Резервирование vs DR

| Понятие | Фокус | Горизонт |
|---------|-------|----------|
| **Резервирование (redundancy)** | Компонент дублирован «здесь и сейчас» | Минуты (failover) |
| **DR (disaster recovery)** | Восстановление после крупной аварии | Часы–дни |

Резервирование: вторая реплика API в другой зоне.  
DR: весь регион недоступен → переключение на `region-b.example-cloud.com`.

---

## RTO и RPO — договор с бизнесом

| Метрика | Вопрос | Пример |
|---------|--------|--------|
| **RPO** (Recovery Point Objective) | Сколько **данных** можно потерять? | «Не больше 5 минут транзакций» |
| **RTO** (Recovery Time Objective) | За сколько **время** сервис снова online? | «Каталог — 1 час, биллинг — 15 минут» |

Чем меньше RPO/RTO — тем дороже инфраструктура и сложнее эксплуатация.

```text
Сбой в 14:00
├── RPO 1 ч  → восстанавливаем данные на состояние 13:00
└── RTO 4 ч  → сервис должен работать к 18:00
```

---

## Типы бэкапов

| Тип | Описание | RPO | Хранение |
|-----|----------|-----|----------|
| **Полный (full)** | Вся БД | Зависит от интервала | Дорого по объёму |
| **Инкрементальный** | Только изменения с прошлого бэкапа | Меньше | Нужна цепочка восстановления |
| **Снимок (snapshot)** | Моментальный образ диска/тома | Минуты | Быстро, но не замена логическому бэкапу |
| **PITR** | Point-in-time recovery по WAL/логам | Секунды–минуты | PostgreSQL, MySQL enterprise |

**Правило 3-2-1:** 3 копии данных, 2 разных носителя, 1 копия off-site (другой регион/аккаунт).

---

## Репликация данных

| Режим | Задержка | Применение |
|-------|----------|------------|
| **Синхронная** | 0 (ждём подтверждения реплики) | Меньший RPO, выше латентность записи |
| **Асинхронная** | Есть lag | Выше производительность, риск потери последних записей |

Для учебного интернет-магазина: заказы — синхронная или near-sync реплика; аналитика — асинхронная read-replica.

---

## Схемы DR

### Active-Passive (warm / cold standby)

```text
Регион A (active)  ──репликация──►  Регион B (standby, минимум ресурсов)
         │                                    │
    пользователи                          ждёт failover
```

- **Плюсы:** дешевле, проще данные (один writer).
- **Минусы:** RTO выше, нужна процедура переключения DNS/трафика.

### Active-Active

Оба региона принимают трафик. Требует **разрешения конфликтов записи** (CRDT, sharding по региону, «home region» пользователя).

- **Плюсы:** низкий RTO, лучшая латентность глобально.
- **Минусы:** сложность, split-brain без кворума.

Для старта почти всегда достаточно **active-passive + регулярные учения**.

---

## Runbook восстановления

Документ (не в голове одного человека) с шагами:

1. Кто объявляет инцидент (роль on-call).
2. Как проверить масштаб (метрики, статус облака).
3. Failover БД: команды или кнопка в консоли.
4. Переключение DNS / ingress на резервный регион.
5. Проверка smoke-тестов.
6. Коммуникация пользователям (status page).

**Учения DR** раз в квартал: восстановить staging из бэкапа в чистый кластер. Без учений RTO на бумаге — фантазия.

---

## Облачные building blocks

| Сервис (обобщённо) | Роль |
|--------------------|------|
| Managed DB с Multi-AZ | Авто-failover внутри региона |
| Object storage + versioning | Неизменяемые бэкапы файлов |
| Cross-region replication | Копия бакета в другом регионе |
| DNS с health check | Отвод трафика от мёртвого региона |
| Secrets в vault | Одинаковые секреты в DR-регионе (ротация!) |

Имена провайдеров различаются; принципы — одинаковые.

---

## Типичные провалы

| Проблема | Последствие |
|----------|-------------|
| Бэкап не тестировали | «Файл бэкапа повреждён» в день аварии |
| Секреты только в prod-A | DR-регион не поднять |
| Огромный RPO на очереди сообщений | Потеря заказов после failover |
| Нет мониторинга lag реплики | Тихая деградация до суток отставания |

---

## Чеклист для архитектора

- [ ] RTO/RPO согласованы с владельцем продукта
- [ ] Бэкапы автоматические, retention задан
- [ ] Restore проверен на staging за последние 90 дней
- [ ] Runbook в репозитории, ссылка в on-call
- [ ] Критичные данные: список и приоритет восстановления

---

## Самопроверка

1. Чем RPO отличается от RTO?
2. Что означает правило 3-2-1?
3. Когда выберете active-passive вместо active-active?
4. Зачем нужны DR-учения, если бэкапы «настроены автоматически»?

---

## Дальше

→ [Circuit breaker и retry](circuit-breaker-i-retry.md)  
← [Отказоустойчивость](otkazoustojchivost.md)