Backups & restore
Тема дорожной карты · DevOps Engineer
Резервные копии — это снимки данных и конфигурации на определённый момент времени, позволяющие восстановиться после случайного удаления, повреждения, шифровальщиков или сбоев целого региона. Полезная стратегия резервирования определяет RPO (сколько данных можно потерять) и RTO (как быстро нужно восстановиться), следует правилу 3-2-1 (3 копии, 2 типа носителей, 1 вне площадки) и регулярно проверяется учебными восстановлениями — непроверенный бэкап бэкапом не является.
Как это работает
Backups & restore — инженерная практика поддержания данных доступными, сохранными и восстанавливаемыми при сбоях. Инструментарий: реляционные БД (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) и прогнозирование роста по реальному трафику.
Когда применять
Инвестируйте в Backups & restore с момента появления платящих пользователей или бизнес-критичных данных. Порядок: ночные бэкапы, проверенные ежеквартальными 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 — ежеквартально.