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

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

Сначала зафиксируй не «бэкап», а точку восстановления: база, конфиг трекера, схемы postback, шаблоны офферов, whitelist доменов, cron и ключи интеграций. Если это лежит в разных местах без инвентаря, восстановление превращается в ручную археологию.

Минимальный набор:
— ежедневный dump БД с проверкой на битость
— копия конфигов вне сервера
— экспорт правил редиректов и фильтров
— список внешних зависимостей: proxy, DNS, S3, SMTP, API
— отдельный доступ к секретам, а не в том же volume, где приложение

Второй слой — не хранение, а проверка восстановления. Раз в цикл поднимай стенд из бэкапа в чистом окружении и прогоняй цепочку: клик, редирект, срабатывание postback, запись conversion. Если не тестируешь restore, у тебя не бэкап, а архив.

Для отказоустойчивости держи разнесёнными: БД, файлы, очередь задач, логи. Трекер часто падает не сам по себе, а из-за заполненного диска, сломанного cron или недоступного внешнего endpoint'а. Мониторинг диска, latency БД и ошибок webhook'ов важнее, чем красивый uptime-баннер.

Если нужен рабочий DR-план, думай в терминах RPO и RTO, а не «сохраняем раз в сутки». Восстановление трекера должно быть повторяемым: один сценарий, один ответственный, один чек-лист на запуск.