Политики хранения Veeam B&R — распутываем бэкапные цепи вместе с техподдержкой
Приветствую читателей нашего блога! Отчасти мы уже знакомы — мои англоязычные посты появлялись здесь в переводе моей дорогой коллеги polarowl. На этот раз я решил обратиться к русскоязычной аудитории напрямую.
Для своего дебюта мне хотелось найти тему, интересную максимально широкой аудитории и требующую детального рассмотрения. Даниэль Дефо утверждал, что любого человека ждут смерть и налоги. Со своей стороны могу сказать, что любого инженера поддержки ждут вопросы по политикам хранения точек восстановления (или если проще — ретеншену). Как работает ретеншен, я начал объяснять 4 года назад, будучи младшим инженером первого уровня, продолжаю объяснять и сейчас, уже являясь тим лидером испано- и италоговорящей команды. Уверен, что мои коллеги со второго и даже третьего уровня поддержки тоже регулярно отвечают на те же вопросы.
В этом свете мне захотелось написать окончательный, максимально подробный пост, к которому русскоязычные пользователи могли бы возвращаться снова и снова как к справочнику. Момент подходящий — недавно выпущенная юбилейная десятая версия добавила новые возможности к базовому функционалу, не менявшемуся годами. Мой пост ориентирован прежде всего на эту версию — хотя большая часть написанного верна и для предыдущих версий, кое-что из описанного функционала вы там попросту не найдете. Наконец, заглядывая немного в будущее, скажу что в следующей версии ожидаются некоторые изменения, но об этом мы расскажем когда придет время. Итак, приступим.
Задания резервного копирования (Backup job)
Для начала разберем ту часть, которая не претерпела изменений в версии 10. Политика ретеншена определяется несколькими параметрами. Откроем окно создания нового задания и перейдем на вкладку Storage. Здесь мы увидим параметр, определяющий желаемое количество точек восстановления:
Однако, это только часть уравнения. Реальное количество точек определяется также режимом бэкапа, установленным для задания. Для выбора этого параметра нужно кликнуть по кнопке Advanced на той же вкладке. Это откроет новое окно со множеством опций. Пронумеруем их и рассмотрим поочередно:
Если включить только опцию 1, то задание будет работать в «бесконечно инкрементальном» режиме (forever forward incremental). Тут никаких сложностей не возникает — задание будет хранить установленное количество точек восстановления от полного бэкапа (файл с расширением VBK) до последнего инкремента (файл с расширением VIB). Когда количество точек превысит установленное значение, самый старый инкремент будет объединен с полным бэкапом. Иными словами, если задание установлено хранить 3 точки, то сразу после очередной сессии на репозитории будет 4 точки, после чего полный бэкап будет объединен со самым старым инкрементом и общее количество точек вернется к 3.
Также предельно прост ретеншен для «обратно-инрементального» (reverse incremental) режима (опция 2). Поскольку в этом случае самая новая точка будет полным бэкапом, за которым будет тянуться цепочка так называемых роллбэков (файлы с расширением VRB), то для применения ретеншена достаточно просто удалить самый старый роллбэк. Ситуация будет такой же: сразу после сессии количество точек превысит установленное на 1, после чего вернется к нужному значению.
Учтите, что с обратно-инкрементальным режимом можно также включить периодический полный бэкап (опция 4), но сути это не поменяет. Да, в цепочке появятся полные точки восстановления, но мы все так же будемт просто удалять самые старые точки по одной.
Наконец, мы подходим к интересной части. Если активировать инкрементальный бэкап, но вдобавок включить опции 3 или 4 (а можно и обе одновременно), задание начнет создавать периодические полные бэкапы «активным» или синтетическим методом. Метод создания полного бэкапа не важен — он будет содержать те же данные, а инкрементальная цепочка будет разделена на «подцепочки». Такой метод называется forward incremental, и именно он вызывает значительную часть вопросов у наших клиентов.
Ретеншен тут применяется удалением самой старой части цепочки (от полного бэкапа до инкремента). При этом мы не будем удалять только полый бэкап или только часть инкрементов. Вся «подцепочка» удаляется полностью за раз. Меняется и смысл настройки количества точек — если в других методах это максимально допустимое количество, после которого нужно применять ретеншен, то тут эта настройка определяет минимальное количество. Иными словами, после удаления самой старой «подцепочки», количество точек в оставшейся части не должно упасть ниже этого минимума.
Постараюсь изобразить эту концепцию графически. Допустим, ретеншен выставлен на 3 точки, задание работает каждый день с полныйм бэкапом в понедельник. Ретеншен в таком случае будет применен, когда общее количество точек достигнет 10:
Почему аж 10, когда выставили 3? В понедельник был создан полный бэкап. Со вторника по воскресенье задание создавало инкременты. Наконец, в следующий понедельник вновь создается полный бэкап и только когда будут созданы 2 инкремента наконец-то вся старая часть цепочки может быть удалена, потому что оставшееся количество точек не упадет ниже установленных 3.
Если идея понятна, то предлагаю вам попробовать посчитать ретеншен самостоятельно. Возьмем такие условия: задание запускается в первый раз в четверг (естественно, будет сделан полный бэкап). Задание выставлено создавать полный бэкап по средам и воскресеньям и хранить 8 точек восстановления. Когда ретеншен будет применен в первый раз?
Для ответа на этот вопрос я рекомендую вам взять лист бумаги, расчертить его по дням недели и написать, какая точка создается каждый день. Ответ станет очевидным
Пояснение: для ответа достаточно спросить себя «когда будет применен ретеншен»? Ответ — когда мы сможем удалить 3 первые точки (VBK, VIB, VIB) и остальная цепочка не упадет ниже положенных 8 точек. Становится ясно, что мы сможем это сделать, когда у нас будет 11 точек в сумме, т. е. в воскресенье второй недели.
Некоторые читатели могут возразить: «зачем все это, если есть rps.dewin.me?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Наконец, мы не рассмотрели опцию «Transform previous backup chains into rollbacks» (отмечена цифрой 5). Эта опция иногда смущает клиентов, которые активируют ее «на автомате», желая включить просто синтетический бэкап. Между тем, эта опция активирует совершенно особенный режим бэкапа. Не вдаваясь в подробности, сразу скажу, что на данном этапе развития продукта «Transform previous backup chains into rollbacks» — опция устаревшая, и я не могу придумать ни одного сценария, когда бы ее следовало использовать. Ее ценность настолько сомнительна, что некоторое время сам Антон Гостев бросил клич через форум, прося прислать ему примеры ее полезного использования (если у вас они есть, напишите в комментариях, мне очень интересно). Если таковых не найдется (я думаю, так и будет), то опцию удалят в следующих версиях.
Задание будет создавать инкременты (VIB) до дня, когда назначен синтетический полный бэкап. В этот день действительно создается VBK, но вот все точки до этого VBK трансформируются в роллбэки (VRB). После этого задание продолжит создавать инкременты к полному бэкапу до следующего синтетического бэкапа. В итоге в цепочке создается гремучая смесь из VBK, VBR и VIB файлов. Ретеншен же применяется очень просто — удалением последнего VBR:
Проблемы
Помимо собственно понимания как это работает, большинство проблем, возникающих при использовании инкрементального режима, обычно связаны с полным бэкапом. Регулярный полный бэкап необходим этому режиму, иначе репозиторий будет копить точки, пока не переполнится.
Например, полный бэкап может создаваться слишком редко. Скажем, задание выставлено хранить 10 точек, а полный бэкап создается раз в месяц. Понятно, что фактическое количество точек тут будет значительно больше выставленного. Или же задание вообще выставлено работать в бесконечно-инкрементальном режиме и хранить 50 точек. Затем кто-то случайно создал полный бэкап. Все, отныне задание будет ждать, пока полная точка накопит 49 инкрементов, после чего применит ретеншен и вернется в бесконечно-полный режим.
В других случаях полный бэкап выставлен создаваться регулярно, но по какой-то причине этого не делает. Распишу здесь самую популярную причину. Некоторые клиенты предпочитают использовать опцию расписания «run after» и настраивать задания работать в цепочке. Возьмем такой пример: есть 3 задания, которые работают каждый день и создают полный бэкап в воскресенье. Первое задание запускается в 22.30, остальные запускаются по цепочке. Инкрементальный бэкап занимает 10 минут, и поэтому к 23.00 все задания заканчивают работу. А вот полный бэкап занимает час, поэтому в воскресенье происходит следующее: первое задание работает с 22.30 до 23.30. Следующее с 23.30 до 00.30. А вот третье задание запускается уже в понедельник. Полный бэкап настроен на воскресенье, поэтому в таком случае его попросту не будет. Задание же будет ждать полный бэкап чтобы применить ретеншен. Поэтому будьте внимательны при использовании опции «run after» или не используйте ее вообще — просто выставьте задания стартовать в одно время и позвольте планировщику ресурсов сделать свою работу.
Непростая опция «Remove deleted items»
Пройдя по настройкам задания Storage — Advanced — Maintenance, можно наткнуться на опцию «remove deleted items data after», исчисляемую днями.
Некоторые клиенты ожидают, что это и есть ретеншен. На самом деле, это совершенно отдельная опция, непонимание которой может привести к неожиданным последствиям. Однако, прежде всего нужно объяснить, как B&R реагирует на ситуации, когда за время сессии успешно бэкапятся только несколько машин.
Представим такой сценарий: бесконечно-инкрементальное задание, настроенное хранить 6 точек. В задании 2 машины, одна всегда бэкапилась успешно, другая иногда давала ошибки. В итоге к седьмой точке сложилась такая ситуация:
Время применять ретеншен, но у одной машины 7 точек, а у другой только 4. Будет ли тут применен ретеншен? Ответ — да, будет. Если хоть один объект был забэкаплен, B&R считает, что точка создана.
Аналогичная ситуация может сложиться, если какая-то машина попросту не была включена в задание во время определенной сессии. Такое бывает, например, когда машины добавлены в задание не индивидуально, а в составе контейнеров (папки, хранилища) и какая-то машина временно мигрирует в другой контейнер. Задание в таком случае будет считаться успешным, но в статистике вы найдете сообщение, призывающее обратить внимание, что такая-то машина больше не обрабатывается заданием.
Что же будет, если не обращать на это внимание? В случае с бесконечно-инкрементальным или обратно-инкрементальным режимами количество точек восстановления «проблемной» машины будет убывать с каждой сессией, пока не достигнет 1, сохраненной в VBK. Иными словами, даже если машина не будет бэкапиться долгое время, одна точка восстановления все-таки останется. Дело обстоит иным образом, если включены периодические полные бэкапы. Если игнорировать сигналы от B&R, в итоге последняя точка может быть удалена вместе со старой частью цепочки.
Уяснив эти детали, наконец можно рассмотреть опцию «Remove deleted items data after». Она удалит все точки для определенной машины, если эта машина не бэкпится в течение X дней. Обратите внимание, что на ошибки (попробовали — не получилось) эта настройка не реагирует. Не должно быть даже попытки бэкапа машины. Казалось бы, опция полезна и ее всегда следует держать включенной. Если администратор удалил машину из задания, то логично через некоторое время очистить от ненужных данных и цепочку. Однако, настройка требует дисциплины и внимательности.
Приведу пример из практики: в задание были добавлены несколько контейнеров, состав которых был довольно динамичным. Из-за отсутствия ОЗУ B&R сервер испытывал проблемы, которые оставались незамеченными. Задание запустилось и попыталось сделать бэкап машин, кроме одной, которая на тот момент не присутствовала в контейнере. Поскольку многие машины выдали ошибки, по умолчанию B&R должен выполнить 3 дополнительные попытки сделать бэкап «проблемных» машин. Из-за постоянных проблем с ОЗУ, эти попытки растянулись на несколько дней. Повторной попытки сделать бэкап отсутствующей ВМ не было (отсутствие ВМ — это не ошибка). В итоге, во время одной из повторных попыток было выполнено условие «Remove deleted items» и все точки машины были удалены.
По этому поводу могу сказать следующее: если у вас настроены оповещения о результатах заданий, а еще лучше — используется интеграция с Veeam ONE, то скорее всего такого с вами не произойдет. Если же вы заглядываете на B&R сервер раз в недельку, проверить, что все работает, то от опций, которые потенциально могут привести к удалению бэкапов, лучше отказаться.
Что добавилось в v. 10
То, о чем мы говорили до этого, существовало в B&R в течение многих версий. Уяснив эти принципы работы, давайте теперь посмотрим, что добавилось в юбилейной «десяточке».
Daily retention
Выше мы рассматривали «классическую» политику хранения, основанную на количестве точек. Альтернативный подход — выставить в том же меню «days» вместо «restore points».
Идея ясна из названия — ретеншен будет хранить установленное количество дней, количество же точек в каждом дне не имеет значения. При этом нужно помнить следующее:
- Текущий день не учитывается при расчете ретеншена
- Дни, когда задание не работало совсем, тоже считаются. Это следует иметь в виду, чтобы случайно не потерять точки тех заданий, которые работают нерегулярно.
- Точка восстановления считается от того дня, когда началось ее создание (т. е. если задание начало работать в понедельник, а закончило во вторник, то это точка от понедельника)
В остальном принципы применения ретеншена заданиями все также определяются выбранным методом бэкапа. Давайте попробуем еще одно задание на расчет, используя все тот же инкрементальный метод. Скажем, ретеншен выставлен на 8 дней, задание работает каждые 6 часов с полным бэкапом в среду. При этом задание не работает в воскресенье. Задание запускается в понедельник в первый раз. Когда будет применен ретеншен?
Уясняем для себя что ретеншен будет применен удалением понедельничного полного бэкапа и его инкремента. Когда это произойдет? Когда оставшаяся часть цепочки будет содержать 8 дней. При этом мы не считаем текущий день, а вот воскресенье, наоборот, считаем. Поэтому ответ — в четверг второй недели.
Архивирование методом GFS для обычных заданий
До v. 10 метод хранения Grandfather-Father-Son (GFS) был доступен только для заданий создания архивных копий (Backup copy) и заданий копирования на магнитную ленту. Теперь же он доступен и для обычного бэкапа.
Хотя это не относится к текущей теме, не могу не сказать, что новый функционал не означает отхода от стратегии 3–2–1. Присутствие архивных точек в основном репозитории никак не влияет на его надежность. Подразумевается, что GFS будет использован вместе с расширяемым (Scale-out) репозиторием, для отгрузки этих точек в S3 и им подобные хранилища. Если вы им не пользуетесь, то лучше продолжать хранить первичные и архивные точки на разных репозиториях.
Теперь рассмотрим принципы создания GFS точек. В настройках задания, на шаге Storage, появилась специальная кнопка, вызывающая следующее меню:
Суть GFS можно свести к нескольким пунктам (обратите внимание, GFS в других видах заданий работает по-другому, но об этом чуть позже):
- Задание не создает отдельный полный бэкап под GFS точку. Вместо этого будет использован наиболее подходящий полный бэкап из имеющихся. Поэтому задание должно работать в инкрементальном режиме с периодическим полным бэкапом, или же полный бэкап должен создаваться пользователем вручную.
- Если включен только один период (например, недельный), то в начале GFS периода задание просто начнет ждать полный бэкап и отметит первый подходящий как GFS.
Пример: задание настроено хранить недельный GFS, используя бэкап в среду. Задание работает каждый день, но полный бэкап назначен на пятницу. В этом случае в среду начнется GFS период и задание начнет ждать подходящую точку. Она появится в пятницу и будет отмечена флагом GFS.
- Если включены сразу несколько периодов (например, недельный и месячный), то B&R будет применять метод, позволяющий использовать одну и ту же точку как GFS нескольких интервалов (для экономии места). Флаги будут назначены по очереди, начиная с младшего.
Пример: недельный GFS выставлен на среду, а месячный — на последнюю неделю месяца. Задание работает каждый день и создает полные бэкапы по понедельникам и пятницам.
Для простоты начнем отсчет с предпоследней недели месяца. В эту неделю будет создан полный бэкап в понедельник, но он будет проигнорирован, потому что недельный GFS интервал начинается в среду. Зато пятничный полный бэкап полностью подходит для GFS точки. Эта система нам уже знакома.
Теперь рассмотрим, что произойдет в последнюю неделю месяца. Месячный GFS интервал начнется в понедельник, но понедельничный VBK не будет помечен как GFS, потому что задание стремится пометить один VBK и как месячную, и как недельную GFS точку. При этом начинается поиск именно с недельной, потому она же по определению сможет стать и месячной.
При этом если включить только недельный и годовой интервалы, то они будут действовать независимо друг от друга и могут отметить 2 отдельных VBK как соответствующие GFS интервалы.
Задания создания архивной копии (Backup copy)
Еще один тип заданий, часто требующий разъяснений по работе. Для начала разберем «классический» метод работы, без нововведений v. 10
Простой метод ретеншена
По умолчанию такие задания работают в бесконечно-инкрементальном режиме. Создание точек определяется двумя параметрами — интервалом копирования и желаемым количеством точек восстановления (ретеншена по дням тут нет). Интервал копирования выставляется на первой же вкладке Job при создании задания:
Количество точек же определяется чуть дальше на вкладке Target
Задание создает 1 новую точку за каждый интервал (сколько точек было создано для ВМ исходными заданиями, значения не имеет). Под конец интервала новая точка финализируется и, если это необходимо, применяется ретеншен путем объединения VBK и самого старого инкремента. Этот механизм нам уже знаком.
Метод ретеншена с использованием GFS
BCJ тоже умеет хранить архивные точки. Настраивается это на той же вкладке Target, чуть ниже настройки количества точек восстановления:
GFS точки могут создаваться двумя способами — синтетически, используя данные на вторичном репозитории, или же имитируя полный бэкап и считывая все данные с первичного репозитория (активируется опцией, отмеченной цифрой 3). Ретеншен в обоих случаях будет сильно различаться, поэтому рассмотрим их отдельно.
Синтетический GFS
В этом случае GFS точка не создается точно в назначенный день. Вместо этого, GFS точка будет создана, когда VIB того дня, на который было назначено создание GFS точки, будет объединен с полным бэкапом. Это иногда вызывает недопонимание, ведь время идет, а GFS точки все нет. И только могущественный шаман из техподдержки может предсказать, в какой день точка все-таки появится. На самом деле магия не нужна — достаточно посмотреть на выставленные количество точек и интервал синхронизации (сколько точек создается каждый день). Попробуйте подсчитать сами на таком примере: задание выставлено хранить 7 точек, интервал синхронизации — 12 часов (т. е. 2 точки в день). На данный момент в цепочке уже 7 точек, сегодня понедельник, и на этот день назначено создание GFS точки. В какой день она будет создана?
Итак, в понедельник последний инкремент в цепочке помечается как GFS, но никаких других видимых изменений не происходит. Каждый день задание создает 2 новые точки, и ретеншен неумолимо двигает цепочку вперед. Наконец, в четверг приходит время применять ретеншен к тому самому инкременту. Эта сессия займет больше времени, чем обычно — потому что задание «извлечет» нужные блоки из цепочки и создаст новую полную точку. С этого момента в цепочке будет уже 8 точек — 7 в основной цепочке + GFS.
Создание GFS точек с опцией «Read entire point»
Выше я сказал, что BCJ работает в бесконечно-инкрементальном режиме. Сейчас мы разберем единственное исключение из этого правила. При включении опции «Read entire point» GFS точка будет создана ровно в запланированный день. Само же задание будет работать в инкрементальном режиме c периодическими полными бэкапами, который мы разбирали выше. Ретеншен также будет применяться удалением самой старой части цепочки. Однако в данном случае будут удалены только инкременты, а полный бэкап будет оставлен как GFS точка. Соответственно, при расчете ретеншена не учитываются точки, отмеченные GFS флагами.
Допустим, задание выставлено хранить 7 точек и создавать недельную GFS точку в понедельник. В этом случае каждый понедельник задание действительно будет создавать полный бэкап и помечать его как GFS. Ретеншен будет применен, когда после удаления инкрементов из самой старой части, количество оставшихся инкрементов не упадет ниже 7. Вот как это выглядит на схеме:
Итак, к концу второй недели в цепочке в сумме 14 точек. В течение второй недели задание создало 7 точек. Будь это простое задание, ретеншен был бы уже применен. Но это BCJ с GFS ретеншеном, поэтому GFS точки мы не считаем, а, значит, их только 6. То есть ретеншен мы еще применить не можем. На третьей неделе мы создаем еще один полный бэкап с GFS флагом. 15 точек, но эту мы опять не считаем. И, наконец, во вторник третьей недели мы создаем инкремент. Теперь, если мы удалим инкременты цепочки первой недели, общее количество инкрементов удовлетворит установленному ретеншену.
Как уже говорилось выше, в данном методе очень важно, чтобы полные бэкапы создавались регулярно. Скажем, если выставить основной ретеншен на 7 дней, но только 1 годовую точку, несложно представить, что инкрементов накопится сильно, сильно больше, чем 7. В таких случаях лучше использовать синтетический метод создания GFS.
И снова «Remove deleted items»
Эта опция также присутствует и для BCJ:
Логика этой опции здесь такая же, как и в обычных задания бэкапа — если машина не обрабатывается указанное количество дней, то ее данные удаляются из цепочки. Однако, для BCJ полезность этой опции объективно выше, и вот почему.
В обычном режиме BCJ работает в бесконечно-инкрементальном режиме, поэтому если в какой-то момент машина удаляется из задания, то ретеншен постепенно удалит все точки восстановления, пока не останется одна-единственная — в VBK. Теперь представим, что задание еще настроено создавать синтетические GFS точки. Когда придет время, задание должно будет создать GFS для всех машин в цепочке. Если у какой-то машины совсем нет новых точек — ну что же, придется использовать ту, что есть. И так каждый раз. В итоге может сложиться такая ситуация:
Обратите внимание на секцию Files: у нас есть основной VBK и 2 недельные GFS точки. А теперь на секцию Restore points — по факту в этих файлах лежит один и тот же образ машины. Естественно, никакого смысла в таких GFS точках нет, они только занимают место.
Такая ситуация возможна только при использовании синтетического GFS. Чтобы этого не допустить, используйте опцию «Remove deleted items». Только не забудьте выставить ее на адекватное количество дней. Техподдержка видела случаи, когда опцию выставляли на меньшее количество дней, чем интервал синхронизации — BCJ начинала неистовствовать и удалять точки, не успев их создать.
Учтите также, что эта опция не трогает уже созданные GFS точки. Если вы хотите почистить архивы, сделать это нужно вручную — кликнув правой кнопкой по машине и выбрав «Delete from disk» (в появившемся окне не забудьте выставить галочку «Remove GFS full backup»):
Нововведение v. 10 — немедленная копия (immediate copy)
Разобравшись с «классическим» функционалом, перейдем к новому. Нововведение одно, но очень важное. Это — новый режим работы.
Тут нет такого понятия, как «интервал синхронизации», задание будет постоянно следить, не появились ли новые точки, и копировать их всех, сколько бы их ни было. Но при этом задание остается инкрементальным, то есть даже если основное задание создает VBK или VRB, эти точки будут скопированы как VIB. В остальном в этом режиме нет никаких сюрпризов — как стандартный, так и GFS ретеншен работают по правилам, описанным выше (правда, тут доступен только синтетический GFS).
Кружатся диски. Особенности репозиториев с ротацией дисков (rotated drives)
Постоянная угроза вирусов-шифровальщиков сделала де-факто стандартом безопасности наличие копии данных на носителе, куда вирус добраться не может. Один из вариантов — это использование репозиториев с ротацией дисков, когда диски используются по очереди: в то время как один диск подключен и доступен для записи, остальные хранятся в безопасном месте.
Чтобы научить B&R работать с такими репозиториями, необходимо в настройках репозитория, на шаге Repository, клинуть по кнопке Advanced и выбрать соответствующую опцию:
После этого VBR будет ожидать, что периодически существующая цепочка будет исчезать с репозитория, что означает ротацию диска. В зависимости от типа репозитория и вида задания, B&R будет вести себя по-разному. Представить это можно вот такой таблицей:
Рассмотрим каждый вариант.
Обычное задание и Windows репозиторий
Итак, у нас есть задание, которое сохраняет цепочки на первый диск. При ротации созданная цепочка фактически исчезает, и заданию нужно как-то пережить эту утрату. Утешение оно находит в создании полного бекапа. Таким образом, каждая ротация означает полный бэкап. Но что происходит с точками на отключенном диске? Они запоминаются и учитываются при просчете ретеншена. Таким образом, выставленное количество точек в задании — это то, сколько точек необходимо держать на всех дисках. Приведем пример:
Задание работает в бесконечно-инкрементальном режиме и настроено хранить 3 точки восстановления. Но у нас есть еще второй диск, и мы раз в неделю проводим ротацию (дисков может быть и больше, это сути не меняет).
В первую неделю задание будет создавать точки на первом диске и объединять лишние. Таким образом, общее количество точек будет равно трем:
Затем мы подключаем второй диск. При запуске B&R заметит, что диск сменился. Цепочка на первом диске исчезнет из интерфейса, но информация о ней останется в базе. Теперь задание будет держать 3 точки на втором диске. Общая же ситуация будет такая:
Наконец, мы вновь подключаем первый диск. Перед создаем новой точки задание проверит, что там с ретеншеном. А ретеншен, напоминаю, выставлен хранить 3 точки. Между тем у нас есть 3 точки на диске 2 (но он отключен и хранится в надежном месте, куда B&R добраться не может) и 3 точки на диске 1 (а вот этот подключен). Значит, можно смело удалить 3 точки с диска 1, поскольку они превышают ретеншен. После чего задание снова создает полный бэкап, и наша цепочка начинает выглядеть так:
Если ретеншен настроен хранить дни вместо количества точек, то логика не меняется. Кроме того, GFS ретеншен не поддерживается совсем при использовании репозиториев с ротацией дисков.
Обычное задание и Linux репозиторий\сетевое хранилище
Такой вариант тоже возможен, но в целом менее рекомендован из-за наложенных ограничений. На ротацию диска и исчезновение цепочки задание будет реагировать так же — созданием полного бэкапа. Ограничение же связано с обрезанным механизмом ретеншена.
Тут при ротации вся цепочка на отключенном диске просто удаляется из базы данных B&R. Обратите внимание — из базы данных, сами файлы при этом остаются на диске. Их можно импортировать и использовать для восстановления, но нетрудно догадаться, что рано или поздно такие забытые цепочки заполнят весь репозиторий.
Решение — в добавлении DWORD ForceDeleteBackupFiles как это указано на этой страничке: www.veeam.com/kb1154. После этого задание начнет просто удалять все содержимое папки задания или папки репозитория (в зависимости от значения) при каждой ротации.
Одако это не элегантный ретеншен, а именно чистка всего содержимого. К сожалению, техподдержке встречались случаи, когда в качестве репозитория был указан просто корневой каталог диска, где помимо бэкапов лежали и другие данные. Все это было уничтожено при ротации.
Кроме того, при включении ForceDeleteBackupFiles работает для всех типов репозиториев, то есть даже репозитории на Windows перестанут применять ретеншен и начнут удалять содержимое. Иными словами, локальный диск на Windows — лучший выбор для такой системы хранения бэкапов.
Backup copy и Windows репозиторий
С BCJ все становится еще интереснее. Мало того, что тут есть полноценный ретеншн, но тут не требуется делать полный бэкап при каждой смене диска! Работает это так:
Сначала B&R начинает создавать точки на первом диске. Скажем, мы выставили ретеншен на 3 точки. Задание будет работать в бесконечно-инкрементальном режиме и объединять всё лишнее (напоминаю, GFS ретеншен в этом случае не поддерживается).
Затем мы подключаем второй диск. Поскольку на нем еще нет цепочки, то мы создаем полный бэкап, после чего у нас появляется вторая цепочка из трех точек:
Наконец, приходит время снова подключить первый диск. И вот тут-то начинается магия, поскольку задание не создаст полный бэкап, а вместо этого просто продолжит инкрементальную цепочку:
После этого фактически на каждом диске будет существовать своя независимая цепочка. Поэтому ретеншен тут означает не количество точек на всех дисках, а количество точек на каждом диске в отдельности.
Backup copy и Linux репозиторий\сетевое хранилище
И вновь, вся элегантность пропадает, если репозиторий не на локальном диске Windows. Этот сценарий работает аналогично рассмотренному выше с простым заданием. При каждой ротации BCJ будет создавать полный бэкап, а существующие точки будут забыты. Чтобы не остаться без свободного места, нужно использовать DWORD ForceDeleteBackupFiles.
Заключение
Итак, в результате такого длинного текста мы рассмотрели два типа задания. Конечно, заданий намного больше, но рассмотреть их всех не получится в формате одной статьи. Если после прочтения у вас остались какие-то вопросы, то пишите их в комментарии, я буду рад ответить лично.
