Ответ
Резервирование — это основа отказоустойчивости. В своей работе я выстраиваю стратегию бэкапов и репликации для следующих ключевых сущностей, отталкиваясь от целевых показателей RPO (допустимая потеря данных) и RTO (целевое время восстановления).
1. Данные (Самое критичное):
- Базы данных: Использую комбинацию методов.
- Репликация (для RPO~0): Настроил логическую репликацию PostgreSQL для критичных данных и мастер-слейв репликацию в MySQL.
- Point-in-Time Recovery (PITR): Регулярные WAL-бэкапы в PostgreSQL с архивацией в S3.
- Пример выгрузки для минорных БД:
pg_dump -U deploy -h db-primary -Fc myapp_prod > /backups/db_$(date +%Y%m%d).dump
- Файловые хранилища: Все пользовательские загрузки и статика хранятся в S3 с включённой версионностью и кросс-региональной репликацией.
2. Конфигурация и код:
- Infrastructure as Code (IaC): Весь код Terraform и конфигурации Ansible хранятся в Git (GitLab). Основной репозиторий зеркалируется на GitHub для резервирования.
- Конфигурации сервисов: Конфиги Nginx, systemd-юниты, файлы окружения также версионируются в Git.
- Артефакты сборки: Docker-образы пушатся в приватный Registry (Harbor), который реплицируется между дата-центрами. Резервные копии образов также хранятся в облачном хранилище.
3. Сама инфраструктура:
- Ключи доступа и секреты: Резервные копии мастер-ключа HashiCorp Vault хранятся в сейфе и у нескольких ответственных инженеров.
- Зоны DNS: Конфигурация зон ведётся как код в Terraform, что позволяет восстановить DNS за минуты.
Правила хранения и проверки:
- Правило 3-2-1: Минимум 3 копии данных, на 2 разных типах носителей, 1 копия географически удалённо (например, S3 Glacier в другом регионе).
- Регулярное тестирование восстановления: Раз в квартал я провожу процедуру восстановления тестовой БД из бэкапа на отдельном стенде, чтобы убедиться в работоспособности процесса и уложиться в целевой RTO.