Backup трекера на больших объёмах: схема, которая не убивает базу и восстановление

Backup трекера на больших объёмах: схема, которая не убивает базу и восстановление

Если трекер живёт на потоке, бэкап «одним архивом ночью» быстро превращается в проблему: dump растёт, окно копирования сдвигается, восстановление занимает часы. Рабочая схема — разделить данные по типу и держать разные правила для hot и cold.

— конфиги, шаблоны, правила, postback-роутинг — в git или отдельный файловый backup;
— базу событий — через инкрементальные снимки + WAL/binlog;
— тяжёлые логи и сырые клики — в отдельное хранилище с ротацией и TTL;
— медиаресурсы и ассеты — отдельно, без смешивания с транзакционными данными.

Перед внедрением проверь три вещи: точку консистентности, время восстановления и объём, который реально пролезет в ваш канал копирования. Если dump нельзя поднять в разумный SLA, это не backup strategy, а просто копия данных. Для MySQL/PostgreSQL держи отдельный тест восстановления на чистой машине, иначе бэкап существует только на бумаге.

Полезное правило: сначала описываешь RPO/RTO, потом под них собираешь схему. Для трекера с большим объёмом данных чаще выигрывает связка «полный snapshot раз в N + инкременты между ними + проверка restore по расписанию».

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