Бэкап трекера нужен не «на всякий случай», а под конкретный RTO/RPO: сколько минут простоя терпишь и сколько конверсий готов потерять. Для self-hosted стека это обычно база, конфиги, postback-маршруты, cron-задачи, списки офферов и шаблоны лендингов.
Храни копии раздельно: база — отдельно от файлов, архив — отдельно от прод-сервера, ключи и доступы — вне той же машины. Если всё лежит на одном VPS, это не backup, а дублирование риска.
Проверь восстановление заранее:
— поднять чистый инстанс;
— развернуть схему БД;
— импортировать дамп;
— проверить редиректы, S2S postback и webhook'и;
— сравнить счётчики кликов и конверсий после импорта.
Отдельно зафиксируй порядок запуска: сначала БД и очереди, потом трекер, потом интеграции с источниками трафика и антидетект-автоматизацией. Иначе после рестарта легко получить «живой» UI с мёртвыми постбэками.
Если бэкап не проходил восстановление хотя бы раз в тестовом стенде, он не считается рабочим. Сделай процедуру восстановления частью эксплуатации, а не разделом в документации.
Tracker Lab
@tracker_lab
Disaster recovery для self-hosted трекера: схема, которая спасает после падения сервера
Этот пост опубликован в Telegram-канале Tracker Lab. Подписаться можно по ссылке: @tracker_lab.