Disaster recovery для self-hosted трекера: план, который спасает postback, а не только сервер

Disaster recovery для self-hosted трекера: план, который спасает postback, а не только сервер

Если трекер лежит, у тебя падает не «сайт», а атрибуция: ломаются postback, теряются конверсии, уезжают окна и схлопывается аналитика. DR-план нужен не ради красивого бэкапа, а чтобы быстро восстановить цепочку: БД, конфиг, очереди, webhooks, cron, SSL, DNS.

Первый слой — данные. Бэкапь отдельно: базу, файлы трекера, .env, конфиги балансера, список интеграций, правила фильтрации, шаблоны postback URL. Храни копии вне основного хоста и проверяй не факт создания, а факт восстановления: поднял пустую ноду, развернул дамп, прогнал тестовый клик и тестовую конверсию.

Второй слой — зависимые сервисы. Трекер часто умирает не сам по себе, а из-за Redis, очередей, cron, NTP, диска или сертификата. В DR-чек-листе фиксируй порядок старта: база, кеш, воркеры, веб, потом интеграции. Отдельно держи запасной домен или поддомен для редиректов и postback, чтобы быстро переключить поток без ручной правки всех кампаний.

Третий слой — переключение. DNS TTL держи низким, но не надевайся на него как на магию. Нужен сценарий: кто принимает решение, кто меняет записи, кто проверяет логи, кто отвечает за возврат конверсий. После подъема системы сразу сверяй: клики идут, postback принимаются, дедупликация работает, окна атрибуции не сбились.

Если DR нельзя поднять из головы за 15 минут, это не DR. Документируй путь восстановления так, будто в момент падения у тебя только SSH и один живой бэкап.