Backup стратегии для трекера с большим объёмом данных: без окна простоя и потери атрибуции

Backup стратегии для трекера с большим объёмом данных: без окна простоя и потери атрибуции

Если у трекера растёт объём кликов, конверсий и сырого лога, бэкап «всё в один архив» быстро становится ловушкой. База тяжелеет, окно копирования расползается, а восстановление упирается не в диск, а в последовательность файлов и WAL/redo.

Рабочая схема обычно такая:
— полный снапшот базы по расписанию;
— инкрементальные бэкапы между снапшотами;
— отдельный дамп критичных таблиц: postback-log, conversions, clicks, campaigns;
— регулярный экспорт конфигов, правил фильтрации, шаблонов постбэков и API-ключей;
— хранение бэкапов вне того же хоста, где живёт трекер.

Для больших объёмов важнее не сам факт бэкапа, а консистентность. Снимай бэкап так, чтобы он совпадал с точкой времени: либо через механизм snapshot-aware, либо через репликацию и выгрузку с неё. Иначе при восстановлении получишь базу, где клики есть, а связка с конверсией уже поехала.

Отдельно проверь, что восстанавливается не только SQL, но и весь слой вокруг: бинарники трекера, cron-задачи, webhooks, схемы постбэков, map полей, сертификаты, gzip-архивы логов. Самая частая ошибка — поднять базу, а потом вручную собирать интеграции, которые должны были лежать в backup set.

Делай не один бэкап, а проверяемую цепочку: backup, restore на стенд, сверка счётчиков, сверка последних postback’ов. Если восстановление не тестируется, это не стратегия, а надежда.