[Системное администрирование, Серверное администрирование, Восстановление данных, Резервное копирование] Политики хранения Veeam B&R

[Системное администрирование, Серверное администрирование, Восстановление данных, Резервное копирование] Политики хранения Veeam B&R — прочтите перед апгрейдом

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
15-Июн-2021 12:32

Цитировать

Долгожданный релиз версии 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, где нам наверняка будет что обсудить.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_servernoe_administrirovanie (Серверное администрирование), #_vosstanovlenie_dannyh (Восстановление данных), #_rezervnoe_kopirovanie (Резервное копирование), #_veeam_backup_and_replication, #_veeam, #_rezervnoe_kopirovanie (резервное копирование), #_rezervnye_kopii (резервные копии), #_retention, #_backup, #_blog_kompanii_veeam_software (
Блог компании Veeam Software
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_servernoe_administrirovanie (
Серверное администрирование
), #_vosstanovlenie_dannyh (
Восстановление данных
), #_rezervnoe_kopirovanie (
Резервное копирование
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 01:28
Часовой пояс: UTC + 5