Восстановление, бэкапы и дизастер-план

Бэкап, который ни разу не восстанавливали, — это надежда, а не бэкап. Финальный урок модуля — про порядок загрузки, починку файлов, оффсайт-копии и практический дизастер-тест.

Как Redis восстанавливается при старте

1. Если включён AOF и файл есть — грузится AOF (он обычно новее);
2. иначе — dump.rdb из dir;
3. после загрузки сервер принимает команды; реплики дозагружают хвост по репликации.

Проверка и починка файлов:

redis-check-rdb dump.rdb                    # целостность RDB
redis-check-aof appendonly.aof              # целостность AOF
redis-check-aof --fix appendonly.aof        # усечь оборванный хвост

Политика бэкапов

• Оффсайт: копия RDB/AOF уезжает с хоста (S3/GCS) — смерть датацентра не должна уничтожать бэкапы;
• Копируйте после BGSAVE: файл в момент записи может быть несогласован; снимайте после успешного rdb_last_bgsave_status:ok или используйте снапшот ФС;
• RetentionPolicy: например, почасовые за сутки + дневные за месяц;
• Проверка восстановлением: раз в неделю поднимайте бэкап в тестовый инстанс, проверяйте DBSIZE и контрольные ключи. Автоматизируйте.

# Пример крона: дамп + оффсайт
redis-cli BGSAVE
sleep 5
aws s3 cp /var/lib/redis/dump.rdb s3://backups/redis/$(date +\%Y\%m\%d-\%H).rdb

Модель рисков: что теряется при каком отказе

⚠️ Реплика — не бэкап: FLUSHALL мгновенно исполнится и на репликах. Единственная защита от логической ошибки — снимки/оффсайт с ретеншеном. Для защиты от случайного FLUSHALL также выключите команду или требуйте авторизацию (урок 6.3).

Дизастер-тест: выполните руками

1. Сценарий A (RDB): включите только RDB, запишите 100 ключей, сразу docker kill, поднимите. Сколько ключей вернулось? Это ваш фактический RPO.
2. Сценарий B (AOF everysec): то же с AOF. Записывайте 100 ключей батчем, убивайте сразу; повторите 5 раз, фиксируйте потери.
3. Сценарий C (failover): мастер+реплика+Sentinel; запишите с WAIT 1 200 и без; kill мастера; что вернул новый мастер?
4. Сценарий D (логическая порча): FLUSHALL на мастере; убедитесь, что реплики опустели тоже; восстановите из вчерашнего бэкапа.

Результат теста — таблица «отказ → фактическая потеря → время восстановления» для вашей конфигурации. Она же — часть документации продакшена.

Восстановление в больших масштабах

• Подъём с RDB на 10+ ГБ — минуты: учитывайте в runbook'е время восстановления;
• Для прогрева кеша после восстановления включайте «медленный» запуск трафика (circuit-breaker), иначе БД словит шторм промахов (урок 2.3);
• Миграция между инстансами: redis-cli --rdb dump.rdb --pipe или репликация с последующим свитчем клиентов (zero-downtime путь).

Практика

1. Выполните дизастер-тест A–D и заполните таблицу RPO/RTO.
2. Настройте крон-бэкап с оффсайтом (хоть в соседнюю папку) и автоматическую проверку восстановления раз в неделю.
3. Напишите runbook «Redis упал полностью»: шаги, порядок, ответственные, критерии завершения инцидента.