Disaster recovery
Тема дорожной карты · DevOps Engineer
Disaster Recovery (DR) — это план восстановления сервиса после сбоев, которые обычные бэкапы не покрывают: отказ целого региона, шифровальщики, массовое случайное удаление данных, полная компрометация аккаунта. DR описывается параметрами RTO (целевое время восстановления) и RPO (допустимое окно потери данных). Стратегии — от backup-and-restore (дёшево, медленно) через pilot light и warm standby до multi-site active-active (быстро, дорого). План становится реальным только после сквозной репетиции.
Как это работает
Disaster recovery — инженерная практика поддержания данных доступными, сохранными и восстанавливаемыми при сбоях. Инструментарий: реляционные БД (PostgreSQL, MySQL) с primary/replica-репликацией, point-in-time recovery через WAL archiving; кэш-слои (Redis, Memcached) для горячих чтений; backup-стратегии (pg_dump, pgBackRest, WAL-G, Velero для Kubernetes PV); high-availability паттерны (Patroni для Postgres, Sentinel для Redis); runbooks disaster recovery с RPO/RTO-целями. Capacity planning — это нагрузочное тестирование (k6, Locust) и прогнозирование роста по реальному трафику.
Когда применять
Инвестируйте в Disaster recovery с момента появления платящих пользователей или бизнес-критичных данных. Порядок: ночные бэкапы, проверенные ежеквартальными restore-drill'ами → репликация (sync или async) → automated failover → multi-region replication для серьёзных RPO. Не пропускайте restore-drill — бэкап, который никто не восстанавливал, — это отсутствие бэкапа. Для SaaS ₽249/мес как devroadmap.ru минимальная планка — один Postgres + ежедневный pg_dump в object storage с 7-дневным retention; HA-схемы преждевременны до контрактных SLO по uptime.
Типичные ошибки
Ловушки reliability: непроверенные бэкапы (классика — backup-скрипт "успешен", но дамп corrupted); replication lag, который никто не мониторит, пока replica не отстанет на 4 часа; manual failover, который никто не репетировал; Redis как "база" вместо кэша (по дефолту эфемерный); нет задокументированных RPO/RTO (узнаете на собственной шкуре после инцидента); cap-сюрпризы (БД упирается в 100% CPU на Чёрной пятнице, потому что никто не нагрузил). Game days — ежеквартально.