Сколько хранить бэкапы и по какой схеме ротации

MAATRIX

Рано или поздно у любого, кто настраивает резервное копирование, возникает один и тот же вопрос: а сколько версий вообще хранить? Хранить всё подряд годами — дорого и бессмысленно: диск не бесконечный, а найти нужную копию среди тысяч одинаковых снапшотов сложнее, чем среди десятка осмысленно отобранных. Удалять слишком рано — риск другого рода: проблема обнаруживается через месяц, а нужной версии уже нет. Ниже — рабочая схема ротации, которая закрывает оба риска, и практический способ подобрать сроки под свои данные, а не под чужой шаблон.

Почему «хранить всё» и «хранить последнюю копию» — обе крайности

Два полярных подхода к хранению бэкапов одинаково плохи, просто по разным причинам.

Хранить всё — самый частый первый инстинкт: место относительно дешёвое, диски растут, зачем что-то удалять. На практике это упирается в три проблемы:

• Стоимость растёт линейно, а полезность — нет. Копия за вчера и копия за позавчера почти всегда взаимозаменяемы для целей отката. Копия трёхлетней давности нужна практически никогда — но занимает столько же места, сколько вчерашняя.
• Поиск нужной версии превращается в отдельную задачу. Когда в каталоге тысячи снапшотов без явной структуры, восстановление в стрессовой ситуации (а восстановление почти всегда происходит в стрессовой ситуации) начинается с «так, а какой из них нам нужен» — и это отнимает время, которого обычно и так не хватает.
• Инфраструктура для хранения тоже стоит денег — не только сам объём, но и репликация, шифрование, индексация. Экономика вопроса разобрана отдельно в статье про реальную цену экономии на бэкапах — там же обратный случай: почему совсем отказываться от копий ещё дороже.

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

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

Схема «дед-отец-сын»: суть подхода

Классическая многоуровневая схема ротации бэкапов в англоязычной литературе называется grandfather-father-son (GFS) — «дед-отец-сын». Суть простая: копии делятся на три (или больше) уровня по частоте и по сроку хранения, и на каждом уровне хранится своё количество версий.

Механика ротации на практике выглядит так:

• Каждый день снимается копия и кладётся в пул «дневных». Как только пул превышает заданное число копий (например, 7), самая старая дневная копия либо удаляется, либо — что эффективнее — «повышается» в статус недельной, если совпадает с днём недельного снятия.
• Раз в неделю (например, по воскресеньям) одна из дневных копий помечается как недельная и переживает более долгий срок хранения, чем обычные дневные.
• Раз в месяц одна из недельных копий аналогично помечается как месячная и хранится дольше всех остальных.

Из этого и следует практическая экономия: на горизонте года вы храните не 365 полных копий, а условно 7 дневных + 5 недельных + 12 месячных — то есть порядка 24 точек отката вместо 365, при этом покрывая весь год, а не только последнюю неделю.

Важная деталь: «дед-отец-сын» — это про *схему ротации* точек отката, а не про *способ* снятия копии на каждом уровне. Каким физически способом каждая точка формируется — полным снятием состояния или сохранением только изменений с опорой на предыдущую копию — отдельный вопрос инструмента резервного копирования (borgbackup, restic, kopia и подобные используют дедупликацию и добавочные блоки под капотом, так что «месячная» копия на диске не обязательно занимает столько же места, сколько полная).

Почему частые недавние копии важнее редких старых

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

Типичные причины отката:

• «Вчера обновили конфиг / деплой — что-то сломалось, откатываемся на вчера».
• «На прошлой неделе кто-то случайно удалил таблицу/файлы — нужна копия за пару дней до этого».
• «Сегодня заметили аномалию в данных, вчера всё было нормально — сравниваем со вчерашней копией».

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

Но есть и другой класс случаев, реже, но не менее критичный:

• Проблема с данными обнаруживается не сразу, а спустя недели или месяцы — например, скрытая порча в результате бага, который проявился далеко не сразу, или медленно нарастающее повреждение индекса базы.
• Юридическое или регуляторное требование хранить определённые категории данных не менее заданного срока (разобрано в статье про сроки хранения бухгалтерских данных — для других типов данных сроки и основания будут свои, но принцип «уточнить требование, а не гадать» универсален).
• Аудит или разбор инцидента задним числом, когда нужно посмотреть состояние системы «как было полгода назад», а не восстанавливать его — просто свериться.

Именно для этих редких, но реальных случаев и нужен долгосрочный (месячный) уровень — с низкой плотностью, потому что обращения к нему редки, но с достаточным охватом по времени, чтобы не оказаться в ситуации «а копии как раз за тот период уже нет».

Как определить свой срок хранения: три практических фактора

Универсального «правильного» числа не существует — 7 дневных / 4 недельных / 12 месячных копий это разумная отправная точка, но не догма. Дальше вопрос упирается в три конкретных фактора.

1. Как быстро у вас обычно обнаруживаются проблемы. Это самый важный и при этом самый недооценённый фактор. Если у вас есть мониторинг, алерты и активные пользователи, которые быстро сообщают об ошибках — большинство проблем всплывает в течение часов-дней, и глубокий дневной уровень (7–14 дней) с лихвой покрывает риск. Если данные заливаются пакетами раз в месяц и проверяются только при следующей заливке, а тихая порча может остаться незамеченной надолго — стоит удлинять именно недельный и месячный уровень, потому что дневных копий к моменту обнаружения проблемы уже не останется. Практический способ прикинуть это число — посмотреть историю уже случавшихся инцидентов (тикеты, чат с поддержкой, баг-трекер): через сколько дней в среднем обнаруживалась проблема после её появления. Это не точная наука, но ориентир честнее, чем взятое с потолка число.

2. Есть ли юридические или регуляторные требования к сроку хранения. Для части данных решение принимаете не вы, а закон или договор — бухгалтерские и налоговые документы, логи определённых типов операций, данные, подпадающие под требования к персональным данным. Здесь до настройки ротации стоит явно выяснить минимальный обязательный срок для конкретной категории данных — он может быть длиннее, чем вам кажется разумным с чисто технической точки зрения, и в этом случае долгосрочный уровень ротации подстраивается под юридический минимум, а не под интуицию. Смежная тема — что нужно хранить в логах по закону, если среди резервируемых данных есть журналы событий, а не только состояние приложения.

3. Стоимость хранения на конкретном классе носителя. Если архивное хранилище для «холодных», редко читаемых копий стоит на порядок дешевле «горячего» диска — экономически разумно расширить именно месячный/годовой уровень «на всякий случай», а не экономить на нём ради небольшой разницы в счёте. И наоборот: если весь объём хранится на дорогом быстром хранилище без разделения на классы, тянуть глубину хранения бессмысленно дорого, и правильнее сократить дальний уровень, но обеспечить более надёжное покрытие ближнего. Порядок величин по стоимости длительного хранения на разных классах носителей стоит прикидывать заранее, ориентируясь на актуальный прайс, а не на цифры многолетней давности.

Итоговое правило простое: возьмите базовую схему 7/4/12, а затем растяните или сожмите каждый уровень по этим трём факторам — не наоборот.

Пример конфигурации по типу проекта

Ниже — не единственно верные числа, а отправные точки, которые дальше корректируются под вашу специфику.

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

Автоматизация: правило вместо ручного удаления

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

Логика скрипта ротации концептуально простая: для каждого файла копии в каталоге хранения вычисляется его возраст, и на основе возраста и заданных порогов принимается решение — оставить, повысить в статус более редкого уровня или удалить. Псевдокод, иллюстрирующий идею (без привязки к конкретному инструменту):

для каждой резервной копии в каталоге:
    вычислить возраст = сегодня - дата_копии

    если возраст <= 14 дней:
        оставить как дневную копию

    иначе если возраст <= 42 дня и копия сделана в день недельного снятия:
        оставить как недельную копию
    иначе если возраст <= 42 дня:
        удалить (промежуточная дневная копия, срок дневного хранения истёк)

    иначе если возраст <= 365 дней и копия сделана в день месячного снятия:
        оставить как месячную копию
    иначе если возраст <= 365 дней:
        удалить (промежуточная недельная копия, срок недельного хранения истёк)

    иначе:
        удалить (превышен максимальный срок хранения)

На практике эту логику не обязательно писать с нуля — большинство современных инструментов резервного копирования умеют такую многоуровневую ротацию «из коробки» через параметры хранения (в духе «оставить N дневных, M недельных, K месячных снапшотов»), и достаточно один раз настроить политику, а не описывать возраст файлов вручную. Ключевое отличие такого подхода от простого «удалять всё старше N дней» в том, что он не даёт дневному уровню незаметно «съесть» весь месячный охват — старые точки не пропадают целиком, а прореживаются, сохраняя по одной репрезентативной копии на более длинных интервалах.

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

Частые вопросы