Полные, инкрементальные, дифференциальные и сколько это хранить

Три способа не копировать всё каждый раз

Полная копия терабайтной базы каждую ночь это терабайт трафика и терабайт места ежедневно. Поэтому копируют не всё.

Полный (full) бэкап содержит данные целиком. Восстанавливается из одного архива, занимает максимум места.

Инкрементальный (incremental) содержит изменения с момента прошлого любого бэкапа. Самый лёгкий, но восстановление требует полного плюс всей цепочки инкрементов по порядку.

Дифференциальный (differential) содержит изменения с момента прошлого полного бэкапа. Растёт день ото дня, зато для восстановления нужны всего два архива: полный и последний дифференциальный.

Цена выбора видна при восстановлении

Схема с инкрементами: полный в воскресенье, инкременты в остальные дни. Для восстановления в субботу нужны воскресный полный и шесть инкрементов подряд. Битый вторник ломает всё, что после него.

Схема с дифференциалами: полный в воскресенье, каждый день разница от воскресенья. Для восстановления нужны два архива, а битый вторник портит только вторник.

Инкременты экономят место и время бэкапа, дифференциалы экономят время и надёжность восстановления. Выбор зависит от того, что вам дороже, и от пропускной способности канала.

Дедупликация: другой подход

Инструменты вроде restic, borg и kopia вместо цепочек режут данные на блоки и хранят каждый уникальный блок один раз. Классические системы корпоративного бэкапа (тот же Veeam) тоже дедуплицируют, но цепочку полный-плюс-инкременты при этом сохраняют, так что всё сказанное про битое звено к ним по-прежнему относится.

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

Это ломает привычную арифметику. При дедупликации хранить тридцать ежедневных снимков часто дешевле, чем один полный плюс инкременты, потому что повторяющиеся данные не дублируются вообще.

Обратная сторона: репозиторий становится связанной структурой. Повреждение блока задевает все снимки, где он используется, поэтому у таких инструментов есть отдельная команда проверки целостности.

Ретенция: сколько хранить

Хранить всё вечно нельзя, удалять сразу нельзя тоже. Классическая схема называется дед-отец-сын (GFS) и раскладывает копии по кругам. Сроки ниже это распространённая практика, а не канон, в конкретной системе они настраиваются:

• ежедневные хранятся 7 дней;
• еженедельные 4-5 недель;
• ежемесячные 12 месяцев;
• иногда ещё годовые несколько лет.

Такая пирамида даёт частые точки восстановления для недавних событий и редкие для старых. Логика в том, что вчерашнюю ошибку вы хотите отмотать поминутно, а прошлогодний договор просто найти.

Отдельно стоит подумать про требования регуляторов: в некоторых сферах срок хранения определённых данных задан законом, и он важнее ваших расчётов места.

Порча, которую замечают через месяц

Главный аргумент за длинную ретенцию это не аварии, а тихие ошибки. Баг в приложении месяц портил поле в таблице, никто не замечал. Если у вас есть только копии за неделю, все они уже содержат испорченные данные.

Поэтому глубина хранения должна перекрывать реальное время обнаружения проблем. Неделя это защита от аварии, месяцы это защита от собственного кода.

Что важно запомнить

Инкремент это разница с прошлого бэкапа, дифференциал — с прошлого полного; первый дешевле, второй надёжнее при восстановлении.

Цепочка инкрементов восстанавливается целиком: одно битое звено ломает всё последующее.

Дедупликация делает каждый снимок самодостаточным снаружи и общим внутри, поэтому длинная история стоит недорого.

Схема дед-отец-сын даёт частые точки для свежих данных и редкие для старых.

Глубина хранения выбирается по времени обнаружения тихой порчи, а не только по авариям.

Дальше про снапшоты: чем они отличаются от копии и почему консистентность важнее скорости.