Практикум DR — итоги
Вы прошли учебный цикл Disaster Recovery — от метрик RTO/RPO до restore drill с удалением Docker volume. Ниже — сжатые выводы, которые стоит перенести в свой pet-проект или wiki команды.
Бэкап и DR — разные уровни готовности
Файл dump на диске — необходимое, но недостаточное условие. DR начинается с проверенного runbook — документа, где команды restore уже выполнялись на учении, и дата last successful test restore не старше одного квартала. Если restore ни разу не пробовали, RTO и RPO остаются гипотезами. После практикума у вас есть фактическое время восстановления — опирайтесь на него в переговорах с заказчиком или при выборе частоты бэкапов.
Offsite и правило 3-2-1
Offsite — копия, которая переживает ту же катастрофу, что уничтожает production. Папка ../backups на том же VPS, snapshot EBS без копии в другом регионе или dump на том же Docker volume не выполняют требование offsite. Правило 3-2-1 напоминает держать три экземпляра, два типа носителей и одну географически или логически отделённую копию. Для pet-проекта часто достаточно local dump + object storage cold tier — см. FinOps по стоимости хранения.
RPO и частота бэкапов
RPO (Recovery Point Objective) определяет, как часто нужен pg_dump, snapshot или архив WAL. Интервал cron "раз в сутки" означает RPO до 24 часов в худшем случае. Упражнение с заказом order-after-backup на шаге 3 показало это на данных. Чтобы сузить RPO без enterprise-бюджета, увеличьте частоту dump или изучите WAL archiving в 8.11, бэкапы PostgreSQL.
RTO и runbook
RTO (Recovery Time Objective) зависит от длины runbook, скорости скачивания dump из bucket, готовности Docker-образа и доступности on-call. Автоматизация (скрипт restore, Infrastructure as Code) сокращает ручные ошибки под стрессом. Запишите целевой и фактический RTO рядом в runbook; расхождение — повод для улучшений, а не для скрытия цифр.
Restore drill по расписанию
Учения restore проводят регулярно — раз в квартал минимум для pet-проекта с реальными пользователями, чаще для production. Каждое учение заканчивается post-incident заметкой: RTO, RPO, что сломалось, что исправили в runbook. Метрики из учений полезнее теории из статей — вы уже измерили время на своём железе.
Календарное событие "quarterly restore test" с напоминанием за неделю даёт время скачать свежий dump и проверить доступ к offsite bucket. Пропущенный квартал — повод поднять severity в личном backlog: без drill растёт неизвестность фактического RTO.
Runbook как живой документ
Runbook устаревает, когда меняются имена контейнеров, версии Postgres, пути к bucket или пароли. После каждого deploy, меняющего инфраструктуру, выделите 10 минут на сверку runbook с реальностью. Поле last successful test restore старше 90 дней — красный флаг для pet-проекта с платящими пользователями.
Хороший runbook помещается на одну экранную страницу командами copy-paste. Длинные объяснения держите в шаге 1, в runbook только действия.
FinOps и DR вместе
Offsite dump — recurring cost, пусть и небольшой. Свяжите bucket с budget alert (FinOps practicum) и lifecycle policy: старые dump уходят в cold tier или удаляются через 90 дней. DR без контроля billing иногда заканчивается forgotten bucket на Standard tier за $5–15/мес — не катастрофа, но против духа FinOps.
Куда дальше
Чек-лист — вопросы для самопроверки. Бэкапы PostgreSQL — PITR, Wal-G, физические стратегии для узкого RPO. FinOps для pet-проекта — бюджет на offsite storage без сюрпризов в billing.
Итоговая формула practicum
3-2-1 offsite dump + runbook + quarterly restore drill + measured RTO/RPO — минимально зрелый DR pet-проекта. WAL, multi-region и Patroni добавляют, когда пользователи и метрики вырастают из этой базы.
Самопроверка после practicum
| Вопрос | Да/нет |
|---|---|
| Есть runbook с командами restore | |
| Last test restore < 90 дней | |
| Offsite на другом носителе/region | |
| RTO факт записан | |
| RPO gap демонстрировали |
Три и более "да" — practicum усвоен на рабочем уровне для pet-проекта.