Disaster recovery для self-hosted трекера: что должно поднять связку после падения

Disaster recovery для self-hosted трекера: что должно поднять связку после падения

Если трекер живёт на одном сервере без плана восстановления, это не инфраструктура, а надежда. Базовый DR строится не вокруг “бэкапа раз в неделю”, а вокруг трёх вещей: состояние БД, конфиги интеграций и внешние зависимости.

Сначала фиксируй, что нельзя терять: схемы кампаний, postback URL, токены API, правила фильтрации, настройки доменов, mapping по GEO/UA. Это должно уходить в резерв отдельно от медиафайлов и логов. БД — с регулярным дампом и проверкой восстановления, иначе бэкап существует только на бумаге.

Дальше — точка переключения. У трекера должен быть запасной хост, заранее поднятый с той же ОС, PHP/DB-стеком и доступом к тем же DNS-зонам или proxy layer. Если при аварии надо “вспомнить пароль от панели”, DR уже сломан. Хорошая практика — держать конфиг деплой скриптом, а не руками в интерфейсе.

Проверяй сценарий восстановления как обычный runbook: поднять БД, вернуть конфиги, прогнать тестовый клик, проверить postback, убедиться, что редиректы и логирование не отвалились. Отдельно тестируй TTL, SSL и доступ к сторонним API — именно они чаще ломают восстановление, а не сам трекер.

Делай бэкап так, чтобы его можно было развернуть без импровизации: тогда падение сервера будет просто переключением, а не ночной археологией по логам.