Политики хранения Veeam B&R — прочтите перед апгрейдом
Долгожданный релиз версии 11 нашего флагманского продукта заставил меня снова взяться за перо. Такова цена работы с активно развивающимся софтом — не успеваешь с чувством глубокого удовлетворения закрыть Word, как все написанное начинает устаревать и Сизиф вновь должен толкать свой камень в гору на общее благо.
За время моей работы в Veeam я пережил уже семь крупных апдейтов. Чтобы быть во всеоружии, еще до релиза по каждому я вел конспект, куда записывал все изменения и нововведения. Могу сказать, что по этой нехитрой метрике v. 11 побил все рекорды, обогнав даже юбилейную десяточку. Уверен, о новых фичах будет сказано еще многое, а я же продолжу развивать тему этой серии и расскажу, какие изменения следует ожидать с точки зрения ретеншена.
Первая часть — https://habr.com/ru/company/veeam/blog/515564/
Вторая часть — https://habr.com/ru/company/veeam/blog/525828/
Backup copy job
Если вы хорошо изучили принцип ретеншена в BCJ, то вас может ждать некоторое разочарование — v. 11 сильно перекроила процесс в сторону единообразия с обычным заданием бэкапа. Если же вы не обеспокоились изучением этого замысловатого предмета, то все равно рекомендую прочитать первую часть этой серии постов, из солидарности к коллегам и потому что уже сказанное там в данной статье я повторять не буду.
Начну с простого. Что не изменилось:
Если архивирование методом GFS не включено, то изменений нет, задание все так же будет работать в бесконечно-инкрементальном режиме, и количество точек будет точно соответствовать установленному ретеншену.
Если используется режим периодической копии с опцией «Read entire point» (в режиме немедленной копии эта опция все также отсутствует), то фундаментальный принцип не изменится — задание продолжит работать в инкрементальном режиме с периодическими полными бэкапами в дни GFS.
Самые значительные изменения произошли с синтетическим GFS. Откроем настройки задания на уже известном нам шаге:
Как видите, меню претерпело сильные изменения. Хорошие новости в том, что оно вполне может быть вам уже знакомо — оно точь-в-точь повторяет аналогичное меню из настроек обычного задания. Унификация — пожалуй, главная идея изменений. Так проще разработчикам, клиентам и, самое главное — нам, техподдержке.
Разберем подробнее каждое изменение.
Расписание. Если в прошлой версии момент создания каждой точки устанавливался четко на определенный день, то теперь задание следует «интервальной» системе, уже знакомой по обычным заданиям.
С недельным бэкапом все просто — он создается точно в назначенный день (причем как при «активном», так и при «синтетическом» GFS, но об этом чуть позже).
Месячный GFS имеет только два варианта расписания: в первую неделю месяца и последнюю. Если у вас включен недельный интервал, то задание не будет создавать отдельную месячную точку GFS и просто даст 2 флага подходящей недельной точке.
Возьмем такой пример: задание запускается в первый раз в понедельник и настроено создавать недельные точки в пятницу и месячные точки в первую неделю месяца. В первый день будет создан VBK, который будет относиться к базовой цепочке и не будет иметь флагов GFS (в свойствах бэкап сета такая точка отмечается буквой R). В пятницу будет создан недельный GFS (W). Он же будет помечен месячным флагом (M), потому что он подходит по расписанию. В следующую неделю в пятницу будет создан недельный GFS и так далее.
Если же включен только месячный интервал, то GFS точка будет создаваться в первый день первой или последней недели месяца. Если этот день был пропущен — в следующий, и так далее до конца недели. Если была упущена вся неделя, то поезд ушел до следующего месяца.
Годовой GFS позволяет выбрать месяц, когда будет создана точка. Он также работает в связке с месячным интервалом. Если он включен, то подходящая точка получит сразу оба флага. Если нет, то годовая точка будет создана в первый день месяца с повтором попытки во второй день, и так далее до конца месяца.
Квартальные GFS точки. Их тут нет. Их не было в обычных заданиях, когда туда был добавлен GFS ретеншен, поэтому их нет и тут. Первопричина — почти полное отсутствие пользовательского интереса к квартальному GFS, поэтому смею надеяться, что особого негатива это решение не вызовет.
Единица счисления. Если раньше ретеншен исчислялся количеством точек, то теперь он исчисляется количеством недель, месяцев и лет для соответствующего интервала. Причина изменений — появление режима неизменяемости данных (immutability) для защищенных Linux репозиториев и объектных хранилищ. Изменения в них блокируются на определенное время, соответственно, удобнее, когда и ретеншен, и блокировка используют единую систему счисления.
Синтетический GFS. Еще одно важное изменение. Если раньше синтетический метод создавал GFS точку с солидным лагом (повторюсь, в первой части все расписано), то теперь она создается точно в день GFS. Таким образом, теперь и синтетический GFS использует старый-добрый инкрементальный метод с периодическим полным бэкапом. В установленный день задание скопирует инкрементальную точку, после чего синтезирует из нее полный бэкап. Если же инкрементальная точка по какой-то причине создана не будет, то задание использует наиболее близкую точку из имеющихся на репозитории. В предыдущей статье я также упоминал, что BCJ не учитывает в расчете ретеншена точки, помеченные флагами GFS. Теперь эту особенность убрали, так что все стало совсем-совсем как в обычном задании.
Рассмотрим пример. Задание хранит только недельные GFS точки, создает их каждый вторник, работает ежедневно и настроено хранить 8 точек в основной цепи. Ретеншен отработает, когда «активная» часть наберет 8 точек, включая GFS. При ретеншене будут удалены только инкременты, недельный GFS останется и будет удален отдельно когда истечет GFS ретеншен.
Миграция
Довольно сложный момент в этой истории — это переход от старого метода к новому после апгрейда. Разработчики постарались придумать правила, которые позволяют получить после апгрейда максимально схожие настройки. Но все же не будет лишним проверить результат и поправить, если что не так. В целом правила такие:
Месячный GFS
Расписание с первого понедельника месяца по воскресенье второй недели становится первой неделей месяца.
Расписание с 1 по 15 число месяца также становится первой неделей.
Расписание с третьего понедельника месяца по последнее воскресенье становится последней неделей.
Расписание с 16 по 31 число также становится последней неделей.
Иными словами, если день GFS выпадал на первую половину месяца, то он переносится на первую неделю. Если на вторую половину месяца — то на последнюю неделю.
Квартальный GFS
Квартальное расписание будет пересчитано на месячное по обменному курсу 1 квартальная точка = 3 месячных. Если до этого месячное расписание не использовалось, то оно будет включено. Если уже использовалось — то ретеншен будет увеличен до нужного количества. Конечно, такая математика приведет к увеличению потребления места, но бэкапов всегда лучше хранить больше, чем меньше.
Годовой и недельный GFS
Тут изменения минимальны. Настройки годового GFS становятся менее гранулярными, поэтому будет выставлен только соответствующий старому расписанию месяц. В недельном же никаких изменений не требуется.
На что обратить внимание
При апгрейде есть шанс потерять будущую GFS точку. Рассмотрим такой пример. Задание выставлено хранить 5 точек и создавать недельный GFS каждую среду синтетическим методом.
Такая цепочка может выглядеть так:
Есть какое-то количество недельных GFS точек и основная цепочка. До v. 11 точки GFS создавались с лагом, т. е. в цепочке уже есть инкремент, который в будущем станет GFS точкой (механизм был расписан в первой части).
Переход на v. 11 меняет режим работы, мерджи прекращаются. Задание продолжить создавать инкременты, а в следующую среду создаст GFS точку. Далее следует обычная логика ретеншена задания с периодическими полными бэкапами — когда будет создано 4 инкремента к новой точке, старая цепочка удаляется, вместе с потенциальной GFS точкой.
Если очень важно, чтобы все GFS точки были на месте, выход я вижу один — перед апгрейдом временно уменьшить ретеншен основной цепочки до минимума чтобы заставить задание смерджить инкременты и создать «висящие» GFS точки. Благо, такую операцию нужно провести только один раз.
Если у вас используется только годовой GFS. До v. 11 вполне нормально было настроить задание хранить короткую основную цепочку и создавать только годовые GFS точки синтетическим методом. В v. 11 это приведет к огромному накоплению инкрементов в основной цепочке, потому что это станет аналогичным созданию инкрементального задания с полным бэкапом раз в год. При запуске раз в день такое задание создаст 364 инкремента полному бэкапу + установленное ретеншеном количество точек, прежде чем старая часть цепочки сможет быть удалена.
Решение — держать хотя бы 1 недельную GFS точку. Количество точек в основной цепочке все равно несколько увеличится, но не так критично.
Будьте более внимательными к регулярной работе заданий. Как было сказано, ретеншен GFS точек теперь считается по времени, а не по количеству. В общем случае разницы нет: скажем, если недельные GFS точки создаются регулярно, то можно сказать, что мы храним 5 недельных точек или же что мы храним каждую недельную точку в течение 5 недель — конечный результат одинаковый. Но есть и отличие — что, если задание работает нерегулярно? В 11 версии хранение GFS точки не зависит от создания последующих точек. Прошел срок — и точка будет удалена, даже если новые точки не были созданы. Таким образом, ретеншен стал более предсказуемым, но и требует большей внимательности к работе задания.
Периодическая очистка GFS точек
Этот раздел продолжает тему GFS, но стоит несколько особняком, поэтому я решил его рассмотреть отдельно.
До v. 11 при удалении задания бэкап сет переносился в категорию Disk (Imported). Сюда же помещались и настоящие импортированные бэкап сеты. Такое смешение было не очень интуитивным, поэтому в v. 11 для бэкап сетов, потерявших свои родительские задания, были созданы отдельные разделы, помеченные как (Orphaned). На скриншоте ниже я попытался показать все многообразие категоризации бэкапов:
Как видите, их два — Disk (Orphaned) и Object Storage (Orphaned). С первым все ясно, во второй же попадают точки, выгруженные на объектное хранилище.
При чем же здесь GFS? А при том, что даже если бэкап сет попадает в (Orphaned) категорию, ретеншен для GFS точек не перестает работать. Для обычных точек — да. А вот если на полном бэкапе есть флаг GFS, то B&R сначала подождет, пока флаг будет снят после истечения срока хранения, потом проверит, есть ли завязанные на него инкременты. Если таких нет — то точка будет вычищена. Если вам нужно, чтобы бэкап сет оставался неизменным, вместо удаления задания кликните правой кнопкой по бэкап сету и выберите «Remove from configuration». После этого кликните правой кнопкой по репозиторию и выберите «Rescan». Бэкап сет будет импортирован и помещен под категорией (Imported).
Защищенный репозиторий Linux и режим неизменяемости (immutability)
Гонка вооружений в сфере защиты данных идет полным ходом: пока нехорошие люди в худи и темных очках пытаются не дать пользователям воспользоваться бэкапами, наши разработчики придумывают все новые способы эти бэкапы защитить.
Одной из новинок v. 11 стал Linux репозиторий с повышенной защищенностью. Его фишка — возможность защитить цепочки от манипуляций любым способом, кроме разве что физического при помощи тяжелых предметов.
Я не буду подробно рассматривать устройство самого репозитория, скажу лишь, что он требует наличия постоянного транспортного агента на борту (при переходе на v. 11 с предыдущей версии для его установки нужно прокликать через свойства репозитория). Кроме того, визард вам будет очень настойчиво рекомендовать использовать одноразовые реквизиты, которые будут использованы единожды для установки транспортного агента, а затем удалены.
Весь новый функционал сводится вот к этой настройке:
Время окончания неизменяемости можно посмотреть в свойствах бэкап сета в колонке Immutable until:
3 самые нижние точки относятся к закрытой цепочке. После создания нового VBK их дата окончания неизменяемости уже не обновляется, но и флаг снят не был. Затем идет новая цепочка, с уже несколько обновленной датой. Особняком стоит VBK с GFS флагом, у него свои правила.
Так как же «неизменяемость» влияет на работу ретеншена? Эту настройку следует учитывать, потому что неизменяемые точки не могу быть удалены по ретеншену. Возьмем пример, когда из-за настроек может возникнуть конфликт: задание работает каждый день с полным бэкапом в понедельник и настроено хранить 7 точек. Постоянным читателям не составит труда подсчитать, что цепочка достигнет 14 точек, после чего старая «подцепочка» будет удалена. Теперь добавим к этому неизменяемость в течение 10 дней.
Теперь, когда цепочка накопит 14 точек и пора уже будет применять ретеншен, в статистике задания появится безапелляционное сообщение:
Some backups cannot be deleted according to the retention policy, because they are immutable
В итоге ретеншен будет применен только после окончания неизменяемости для старой части, когда в сумме в цепочке будет уже 17 точек:
Вывод: при расчете ретеншена и вместимости репозитория, учитывайте, что Immutability может влиять на ретеншен в сторону удлинения цепочки.
Коротко об остальном
Прощай, трансформ! Как и ожидалось, в дивном новом мире не нашлось места для странной опции Transform into rollbacks. Расстались мягко: если она была включена до апгрейда, то так и останется. Но в новых заданиях вы ее не найдете. И к лучшему.
Catalyst copy. Фича появилась в v. 10 и явной настройки ретеншена не имела — по умолчанию копии точек удалялись после удаления оригиналов из сорсного StoreOnce, если с момента создания точки прошел 21 день. Теперь эта настройка появилась в интерфейсе (см. ниже). При этом опцию можно отключить совсем, тогда копия цепочки будет соответствовать сорсу 1:1.
Портирование кода из обычного задания в BCJ привело к изменению в логике работы репозиториев с ротацией дисков. Раньше при использовании виндового репозитория BCJ держала независимую цепочку на каждом диске, и выставленный ретеншен считался для каждого диска (т. е. ретеншен 5 точек означал 5 точек на каждом диске). В v. 11 цепочки все еще независимые, но ретеншен считается по всем дискам вместе (5 точек значит 5 точек на всех дисках). Если заметите, что при смене диска задание внезапно удаляет всю цепочку — это оно. Чтобы избежать потерь, выкрутите ретеншен повыше.
В v. 10 тейповые задания считали, что BCJ — это бесконечно-инкрементальное задание, а значит, для него всегда нужно создавать виртуальный синтетический бэкап. В v. 11 все работает согласно законам логики: если у BCJ выключен GFS, то это бесконечно-инкрементальная цепочка, и для нее копия на ленту будет создавать виртуальную синтетику. Если GFS включен, то включен и периодический полный бэкап, а значит, виртуальна синтетика создаваться не будет.
У BCJ теперь тоже есть ретеншен по дням. Минимальный ретеншен составляет 2 дня, но учтите, что минимальное количество точек в цепочке в любом случае будет равно 3.
Заключение
В прошлый раз я опрометчиво объявил, что о ретеншене мне сказать больше нечего. Не буду совершать ту же ошибку, хотя надеюсь отойти от этой темы хотя бы до следующей версии. Если у вас есть предложения, можете написать, чем можно заполнить этот промежуток времени. Если нет — то до встречи в v. 12, где нам наверняка будет что обсудить.
