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

С выходом Veeam Backup & Replication 9.5 Update 4 пользователи получили в свое распоряжение множество новых полезных функций, в том числе и для работы с магнитной лентой. Она, назло скептикам, можно сказать, “живее всех живых” помогает организовать надежное долгосрочное хранение данных. И, конечно, лента пользуется популярностью у наших клиентов — это мы видим и по кейсам, которые приходят в техническую поддержку.

Поэтому сегодня я не только расскажу в деталях о новых возможностях Veeam Backup & Replication 9.5 Update 4b, но и дам комментарии по ряду моментов, на которые следует обратить внимание при архивировании и восстановлении. Итак, приступим.




Параллельное использование библиотек


Уже несколько версий прошло с тех пор, как медиа-пулы в Veeam Backup & Replication стали “глобальными”. Что это дало пользователю?

Теперь можно говорить о понятии High Availability (высокая доступность) и применительно к ленте. Так, пользователь может указать событие, при наступлении которого задание архивирования должно переключиться на следующее ленточное устройство в имеющемся списке. Это события "Library is offline" (библиотека отключена) и "No media available" (отсутствует носитель).

Тут я бы хотел дать подсказку на случай, если вам нужно будет удалить старое устройство из инфраструктуры. Некоторые клиенты сообщали, что им выдавалось сообщение об ошибке, говорившее, что устройство якобы все еще используется медиа-пулом Х. В таком случае рекомендую запустить мастер настройки медиа-пула, перейти на шаг Tapes и там нажать Manage — скорее всего, нужное вам устройство будет показано наряду с другими в открывшемся диалоге Manage Libraries.

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



  • Чтобы включить параллельную обработку, нужно выбрать опцию Active.
  • Чтобы задействовать устройство в случае необходимости переключения на него, выбираем Passive.

Примечание: Можно установить либо все устройства в активный режим, либо одно в активный, а остальные — в пассивный (а не наоборот).

Общие рекомендации по использованию режимов:

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

Как видите, никакого rocket science. Тем не менее, есть несколько важных моментов, на которые я бы хотел обратить ваше внимание:

  1. Параллельную обработку можно использовать даже в рамках одного задания архивирования. Для этого исходный бекап должен быть создан в режиме per-VM, т.е. одна виртуальная машина — одна цепочка резервных копий. Или же, в задание надо добавить сразу несколько бекапов.
  2. Параллельная обработка настраивается, как вы видели, при конфигурировании медиа-пулов. На шаге Options ставим галочку Enable parallel processing for tape jobs using this media pool. Тут же можно указать, сколько пишущих приводов (drives) может быть задействовано при работе с этим пулом — в данном примере это 2.

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


  3. А что с медиа-сетами, спросите вы? Тут всё просто: каждое устройство (привод) работает со своим медиа-сетом.

Впрочем, в каких-то инфраструктурах может потребоваться особое внимание при конфигурации.

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

После разбора деталей обнаружилось, что у клиента был медиа-пул, настроенный на создание нового медиа-сета для каждой сессии задания. Сначала все работало прекрасно, ибо объем данных за каждую сессию отлично умещался на указанное количество кассет. Затем появилось новое устройство, и клиент решил использовать параллельную обработку. Теперь данные распределялись по двум наборам кассет. Поскольку по окончании каждой сессии медиа-сет финализировался, то Veeam Backup & Replication не мог продолжать запись данных на те же кассеты в ходе следующей сессии. Вот почему клиент наблюдал перерасход кассет. В итоге ему пришлось выбирать из двух вариантов: либо настроить исходное задание так, чтобы бэкапы умещались на двух комплектах кассет (что не слишком-то надежно), а медиа-сет сделать непрерывным (continuous), либо отключить параллельную обработку.

Также отмечалось, что параллельная запись двух или более медиа-сетов может привести к путанице в наименованиях. У клиентов получалось, что несколько кассет были записаны в одно и то же время и имели один и тот же порядковый номер. (На самом деле это совершенно в порядке вещей.) Чтобы избежать путаницы, мы рекомендуем добавлять к названию медиа-сета переменную %ID%.

Улучшения в работе GFS


Для начала давайте вспомним, как организована поддержка политики хранения GFS по умолчанию.

  1. В день, на который назначен запуск задания по архивированию с GFS-преобразованием (tape GFS), это задание стартует в полночь (00:00) и затем ждёт прибытия новой точки восстановления, созданной исходным заданием бэкапа.
  2. Если новая точка представляет собой инкрементальный бэкап, то задание tape GFS создаст на ленте виртуальный синтетический полный бэкап.
    Если новая точка — это полный бэкап, то такая точка будет скопирована как есть.
  3. Задание tape GFS будет ждать появления новой точки в течение 24 часов.
  4. Если по истечении этого времени новая точка не появится, то задание tape GFS переключится на предыдущую доступную точку.

    Тут возникает особая ситуация с заданиями переноса резервных копий (backup copy jobs, BCJ) — из-за их непрерывной работы последняя точка остается в заблокированном состоянии на всём протяжении интервала копирования. В зависимости от настроек задания BCJ задание tape GFS может быть вынуждено ожидать целый день, прежде чем переключиться на предыдущую точку.

    Если заданию tape GFS надо создать точки для нескольких интервалов в один и тот же день (например, еженедельную точку и ежемесячную точку), то в этом оно не будет копировать 2 различных точки. Вместо этого в качестве еженедельной и ежемесячной будет задействована одна точка.

Ну и для каждого интервала существует свой медиа-сет. Например, если кассета использовалась для еженедельных архивов, то ежемесячную точку на нее записать нельзя (разве что кассета стерта или помечена как чистая). Это смущает некоторых пользователей — они видят просроченную кассету в медиа-пуле GFS, однако задание tape GFS, похоже, игнорирует ее, запрашивая другую, годную кассету.

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

Что же принесло нам обновление Update 4?

Во-первых, две настройки перекочевали из реестра в интерфейс (GUI):

  1. На шаге Schedule мастера настройки задания tape GFS теперь можно указать любое время запуска этого задания (по умолчанию осталось 00:00).


  2. Кроме того, можно настроить задание tape GFS на немедленное (без ожидания) переключение на предыдущую точку в случае недоступности точки за сегодня. Эта опция находится на шаге Options — Advanced – Advanced:



Также в реестр было добавлено новое значение, которое позволяет заданию tape GFS job использовать кассеты с истекшим сроком хранения данных из любого медиа-сета, а не только ту, что относится к конкретному интервалу. Если вам необходимо поменять эту настройку, пожалуйста, обратитесь в службу поддержки.

Параллельная обработка заданий tape GFS


Если вы посмотрите на документацию с описанием медиа-пула GFS для прошлой версии, то там будет написано, что для заданий tape GFS параллельная обработка не поддерживается. И вот в Update 4 она, наконец, была добавлена.

Этапы процесса такие же, как и при работе с обычными медиа-пулами (см.выше). Будьте внимательны относительно расчетного количества кассет при использовании GFS и параллельной обработки заданий — такая конфигурация требует создания множества медиа-сетов. Можно использовать вот такую формулу:

A (настроенные медиа-сеты) x B (число пишущих приводов) = C (используемые кассеты)

Например, для конфигурации с 5 включенными медиа-сетами и 2 приводами потребуется не менее 10 кассет.

Ежедневный медиа-сет


Основным дополнением к функциональности заданий tape GFS стал ежедневный медиа-сет. Он позволяет объединять обычные задания архивирования и задания с GFS. Так, если вы используете медиа-пулы GFS для долгосрочного архивирования, но наряду с этим задействуете и обычные медиа-пулы для хранения коротких инкрементальных цепочек на кассетах, то для упрощения работы вы можете использовать ежедневный медиа-сет вместо настройки отдельного задания.

Идем в настройки медиа-пула GFS и выбираем там соответствующую опцию:



Отметим, что для работы с ежедневным медиа-сетом нужно настроить и еженедельный.
С ежедневным медиа-сетом задание tape GFS будет каждый день проверять, создало ли исходное задание какие-либо точки (полные или инкрементные), и помещать их на ленту. Если исходное задание создаст несколько точек восстановления, то все они будут помещены на ленту. Это позволяет заполнить “провал” между еженедельными точками GFS и обеспечить возможность восстановления из инкрементной точки. В ходе восстановления Veeam Backup & Replication будет запрашивать кассеты, содержащие ближайший полный бэкап (скорее всего, им окажется еженедельный GFS) и относящиеся к нему инкрементные.

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

Пример


Рассмотрим вот такой сценарий:

Имеется задание резервного копирования, создающее бесконечно-инкрементную цепочку. Оно запускается каждый день в 5 утра. Политика хранения настроена на хранение 14 точек восстановления.

  • Для архивирования на ленту можно настроить задание tape GFS job с ежедневным медиа-пулом, хранящим данные за 14 дней, а также с еженедельным, хранящим данные за 4 недели, и с соответствующими ежемесячными, ежеквартальными и ежегодными.
  • Ежедневный медиа-сет можно настроить на дописывание кассет (без экспорта).
  • Еженедельный GFS-интервал (и более старшие интервалы) финализируют недозаписанные кассеты и экспортируют их после каждой сессии.

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

Такой сценарий изображен на схеме ниже:



Если понадобится выполнить восстановление, Veeam Backup & Replication запросит кассету, содержащую еженедельную точку GFS, и будет использовать кассету из ежедневного медиа-сета для восстановления соответствующих инкрементных точек.

Поддержка кассет типа WORM


WORM расшифровывается как Write Once Read Many. Это значит, что будучи однажды записанной, такая кассета не может быть стерта или перезаписана (это может являться достоинством для ряда сценариев). Однако в работе с таким типом кассет имеются определенные трудности, и прошлые версии Veeam Backup & Replication не поддерживали этот тип. Но теперь с ним также можно работать.

В принципе, работа с кассетами типа WORM не сильно отличается от работы с обычными кассетами.

  1. Сначала нужно создать соответствующий медиа-пул — WORM media pool. Как обычно, есть два типа: стандартный и GFS. Есть лишь одна особенность — нельзя изменить настройки политики хранения.
  2. Затем добавляем кассеты. Тут иногда может возникать путаница — кассеты типа WORM считаются за обычные, и наоборот. Чтобы этого избежать, запомните, что все, что относится к работе с кассетами типа WORM, имеет иконки синего цвета.

Veeam Backup & Replication определяет кассеты типа WORM по штрих-коду либо во время инвентаризации (inventory). Обязательно ознакомьтесь с документацией на ваше ленточное устройство и используйте правильные штрих-коды! Например, библиотеки IBM считают, что буквы от V до Y в составе штрих-кода указывают на кассету типа WORM (см. вот эту статью о штрих-кодах). Неуместное использование этих букв может привести к путанице в работе Veeam Backup & Replication.

Резервное копирование NDMP


В Update 4 можно выполнять резервное копирование и восстановление томов NAS, если они поддерживают протокол NDMP.

  1. Прежде всего необходимо добавить сервер NDMP в представлении Inventory, как описывается в документации (см. руководство пользователя (на англ.языке) ).

    Примечание: Обязательно ознакомьтесь с требованиями и ограничениями в этом разделе (параграфы Requirements и Limitations), среди них есть ряд очень важных пунктов. Например, в текущей версии не поддерживается бэкап NDMP с расширений NetApp Cluster Aware Backup (CAB). В качестве обходного варианта можно настроить node-scoped NDMP, как описано здесь.
  2. После того, как вы добавили сервер NDMP в инфраструктуру, его надо сконфигурировать как исходное место хранения файлов для стандартного задания архивирования файлов file to tape.
  3. Восстановление — аналогично восстановлению любых других файлов, хранящихся на ленте — можно запустить из представления Files.

Важно! Текущая версия Veeam Backup & Replication не поддерживает восстановление отдельных файлов тома, можно восстановить только том целиком.

Алгоритм выбора кассеты


Начну с того, что в Update 4 появился новый показатель использования кассеты — количество сессий чтения/записи. Это значение выводится в свойствах кассеты в поле Wear:



После использования кассеты максимально допустимое (в соответствии с ее спецификациями) количество раз она будет перемещена в медиа-пул Retired media pool.

Те, кто хорошо знаком с архивированием на ленту с помощью Veeam Backup & Replication, в курсе, что мониторить предупреждения от ленточных устройств о недопустимости повторного использования кассеты можно было и раньше.

Новым же является использование принципа сбалансированной нагрузки — то есть при выборе кассеты Veeam Backup & Replication Update 4 будет учитывать наряду с другими факторами и значение параметра Wear (то есть сколько сессий кассета уже отработала).
В общем и целом алгоритм выбора кассеты работает так:



Новое в восстановлении файлов


Теперь после того, как пользователь выбрал нужный бэкап, из него будут восстановлены только те файлы, которые присутствовали в исходной папке во время сессии резервного копирования. Само меню не поменялось, обновилась только логика. Как и раньше, запускаем мастер восстановления и нажимаем Backup Set, чтобы выбрать набор файлов резервной копии, из которого будем восстанавливать данные.



Архивирование клиентских бэкапов на ленту



Эта функция позволяет сервис-провайдерам реализовать новый тип услуг — запись резервных копий данных клиентов на ленту. Все настройки выполняются на стороне провайдера: если у вас для Veeam Backup & Replication установлена лицензия Cloud Provider license (поставщика облачных услуг), то вы сможете добавить клиента в качестве источника задания, проходя по шагам мастера настройки задания архивирования.

Примечание: Такие задания могут работать только с пулами GFS.

Восстановление также выполняется на стороне провайдера. Для восстановления есть вот такие опции:

  • восстановление файлов в исходный облачный репозиторий (существующие файлы будут перезаписаны, и задание будет сопоставлено с восстановленным набором резервных копий)
  • в новый облачный репозиторий
  • на локальный диск

В конце концов, если у клиента есть собственная ленточная инфраструктура, то можно просто отправить кассету по почте и избежать любого сетевого трафика.

Другие новшества


Роль Tape operator. Пользователи с этой ролью смогут выполнять любые действия с кассетами, но не смогут запустить восстановление.

Порядок обработки источников. Теперь вы можете изменить порядок обработки источников (source) аналогично тому, как это делается для виртуальных машин в заданиях резервного копирования.

Включение / исключение данных по маске для заданий архивирования файлов. В предыдущих версиях задания архивирования файлов могли использовать только маски для включения (include). Теперь доступны и маски для исключения (exclude).

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

Автоматическое извлечение кассеты из привода, когда лента заполнена. Это небольшая настройка в логике при работе с автономным ленточным устройством. Как только кассета во время сеанса резервного копирования записывается полностью, она автоматически извлекается из устройства, чтобы человек, находящийся рядом с приводом, мог вставить другую кассету. Это применимо, в частности, для защиты от вирусов-«вымогателей».

В заключение


Множество улучшений в работе с магнитной лентой, реализованных в Update 4, ясно показывает, что этот носитель остается в центре внимания продукт-менеджмента Veeam Backup & Replication. Надеюсь, что эти новые возможности помогут сделать ваше резервное копирование еще эффективнее.

Полезные ссылки