Бэкапы нужно проверять.

В качестве вступления простая история из бурной молодости. Всем знакома ситуация, когда ресурсов нет, а хранить резервные копии нужно. В свое время для хранения резервных копий своих систем, использовалось два диска объемом по 500GB. Как можно было догадаться, при использовании RAID-1, полезное пространство ограничивалось теми самыми 500GB, чего катастрофически не хватало. Было принято решение использовать Linux LVM, тем самым получить 1000GB пространства, в ущерб надежности.

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

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

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

Тем, кому интересно как Veeam проверяет свои резервные копии, прошу под кат.

Допустим, вы уже используете систему резервного копирования Veeam в своей виртуальной инфраструктуре и каждый день получаете уведомление на почту о том, что все бэкапы выполнены, но, к сожалению, это еще не значит, что этими бэкапами можно будет воспользоваться. А причин у этого на самом деле много:

• Как и в примере из жизни, проблемы с дисками могут оказать влияние на расположенные на них резервные копии (самый страшный случай, как по мне);
• Операционная система может не запуститься, если используются неконсистентные бэкапы;
• Приложение, расположенное в системе может плохо чувствовать себя после восстановления системы.

И т.п.

В Veeam Backup&Replication есть интересное решение под названием SureBackup, которое позволяет проверять резервные копии, а так же некоторые приложения, расположенные внутри систем. Для тех, кто не знаком с данной технологией, почитать можно здесь. Получить данную возможность можно обладая лицензиями Enterprise, либо Enterprise Plus.

Алгоритм работы SureBackup довольно прост:

1. Создается изолированная лаборатория на каком-либо хосте в кластере виртуализации;
2. С помощью vPower NFS виртуальная машина из резервной копии запускается в данной лаборатории;
3. Выполняется ряд автоматических тестов;
4. Отправляется отчет о результатах тестового восстановления.

Технология vPower NFS, позволяет запускать виртуальные машины на гипервизорах напрямую из файлов резервных копий.

Список тестов, которые может выполнить SureBackup:

1. Проверка запуска виртуальной машины;
2. Проверка Heartbeat операционной системы (Необходимо наличие VMware tools в гостевой операционной системе);
3. Проверка ping до виртуальной машины;
4. Запуск скриптов для проверки приложений внутри системы (требуется наличие учетной записи для доступа к гостевой ОС).

А теперь о том, как это все настроить.

Я использую тестовую лабораторию, в которой есть кластер VMware ESXi 5.5, Shared Storage, а так же отдельный гипервизор, на котором будет выполняться само тестовое восстановление.
Все адреса вымышлены, любые совпадения случайны.

Настройка SureBackup выполняется непосредственно из консоли Veeam BR, и первое, что необходимо сделать это подготовить виртуальную лабораторию Virtual Lab. Найти ее можно на закладке Backup Infrastructure > SureBackup > Virtual Labs.

Сейчас никаких лабораторий нет, необходимо создать новую:


Кликнув на Add Virtual Lab в первую очередь нас попросят как-то назвать нашу лабораторию и указать ее описание.


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


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


Для взаимодействия с тестовыми виртуальными машинами по сети необходима инсталляция Proxy Appliance. От использования данной возможности можно отказаться, однако в таком случае, многие возможности тестов, такие как тестирование сети, доступ к виртуальным машинам через сеть будут недоступны. Proxy Appliance представляет собой виртуальную машину, которая смотрит одним интерфейсом в рабочую сеть, а остальными, в зависимости от настройки, в изолированные. Данная виртуальная машина разворачивается автоматически при создании виртуальной лаборатории, устанавливать систему и настраивать маршрутизацию вручную не требуется:


Для корректной настройки Proxy Appliance необходимо указать сетевые настройки, при которых данная виртуальная машина будет доступна для сервера Backup & Replication.

Необходимо указать:

Сеть с виртуального свича гипервизора, которую будет использовать данный appliance;
Настройки IP, при которых данный appliance будет доступен для сервера BR;



После указания настроек Proxy Appliance следующим шагом необходимо настроить изолированные сети для нашей виртуальной лаборатории. Вариантов представлено 3:

1. Basic single-host — автоматическая конфигурация сетевых настроек. В данном варианте будет создана только одна изолированная сеть, аналогичная сети, которая была указана в настройках appliance;
   
   
2. Advanced single-host — ручная конфигурация изолированных сетей. Я думаю, что большинство использует не одну сеть для своих виртуальных машин, а несколько сетей, разделенных на VLANs, соответственно для корректного теста сети виртуальных машин с разными сетевыми настройками, нам нужно создать несколько сетей;
   
   
3. Advanced multi-host — Используется, если виртуальную лабораторию необходимо разнести на несколько хостов, например, для тестирования реплик. Использует возможности VMware Distributed Switch (VDS).

Поскольку мне необходимо протестировать виртуальные машины, расположенные в разных сетях, я воспользуюсь вариантом Advanced single-host.

На закладке Isolated Networks система автоматически создает одну изолированную сеть, аналогичную сети, в которой располагается proxy appliance (Виртуальные машины, запущенные в лаборатории из бэкапов, будут подключены к изолированным сетям и не будут вещать в продакшен).

В моем случае это сеть V39 и VLAN ID 39:


Необходимо добавить еще одну сеть, для виртуальных машин из другого VLAN. При нажатии кнопки Add, отобразится окно, в котором необходимо выбрать Production Network, которая соответствует какой-либо из сетей vSwitch и сопоставить ей Isolated Network в виртуальной лаборатории. В моем случае я добавляю сеть V30, которую использует моя виртуальная машина из резервной копии:



В результате формируется следующее правило: Виртуальные машины, сетевой интерфейс которых использует сеть V30 с vSwitch, будут подключены к сети test-vLab1 V30 в виртуальной лаборатории, а виртуальные машины с сетью V39 к сети test-vLab1 V39 соответственно:


Следующий шаг, пожалуй, самый интересный. Используя виртуальную машину proxy appliance, мы можем получить доступ к виртуальным машинам извне, поскольку proxy выступает в качестве маршрутизатора между нашей сетью и изолированной, в которой располагаются тестовые машины. Доступ осуществляется за счет маскарандинга реальных адресов машин, которые находятся в вирутальной лаборатории, при этом сами машины работаю внутри изолированной сети со своими реальными адресами.

По-умолчанию proxy appliance создает только один сетевой интерфейс для первой изолированной сети. Я создам два интерфейса для двух моих сетей V30 и V39:


В первую очередь я изменю настройки для vNIC1 (первый интерфейс виртуальной машины proxy appliance), для взаимодействия с изолированной сетью V39. Сделать это можно нажатием кнопки Edit. Изначально настройки выглядят следующим образом:


А теперь измененные значения для моей сети:


Первое поле — изолированная сеть, в которую будет смотреть наш интерфейс proxy appliance.
Далее указывается адрес и маска, которым прокси будет смотреть в данную сеть, как пишет Veeam, обычно это адрес аналогичный шлюзу данной сети. Виртуальные машины в изолированной сети могут взаимодействовать друг с другом через данный шлюз.

Следующее поле это маскарадинг (подмена адресов). Работает это примерно следующим образом (если я все правильно понимаю):

Я использую маску сети класса C и соответствующую сеть для маскарадинга 192.168.100.XXX.

Как в этом случае работает Veeam? При восстановлении виртуальной машины в тестовую лабораторию, он определяет адрес виртуальной машины. Допустим этот адрес 10.10.10.113.
Затем, поскольку, я использую маску сети /24, из данного адреса берется последний октет, т.е. 113. Формируется маскированный адрес 192.168.100 + 113. В итоге извне моя машина доступна по данному адресу.

Для получения доступа к ней необходимо обновить свою таблицу маршрутизации, где необходимо указать, что на адрес 192.168.100.113 мы будем ходить через шлюз (которым в нашем случае является Proxy Appliance) с адресом 10.10.10.62.

В итоге для двух моих изолированных сетей получается следующая конфигурация:


Следуем далее до Ready to Apply.

По завершению создания Virtual Lab, можно сверить суммарные настройки виртуальной лаборатории, которые будут получены:


И, по нажатию кнопки Next, начнется создание нашей лаборатории. Что делает в этот момент Veeam?

1. На выделенном хосте создается пул ресурсов, в котором будет находиться Proxy Appliance и восстанавливаемые виртуальные машины;


2. Создается виртуальный свитч vSwitch с названием нашей лаборатории;

3. На данном vSwitch создаются виртуальные сети, которые были указаны ранее. test-vLab1 V39 и test-vLab1 V30. Как можно заметить, данный свитч не использует физические сетевые адаптеры, что препятствует попыткам выхода виртуальных машин наружу;


4. Разворачивается виртуальная машина Proxy Appliance (машина располагается на datastore, который был указан в самом начале);

5. В нашем примере у данной виртуальной машины 3 сетевых интерфейса. Первый для подключения к продакшен сети. Данный интерфейс подключен в vSwitch0. Два других для изолированной сети из vSwitch1 (чем больше сетей — тем более интерфейсов):


На этом этап создания виртуальной лаборатории завершен.

Следующим шагом необходимо создать Appliaction Groups — группу виртуальных машин, которая будет запускаться при тестировании. Например DNS, Контроллер домена, Почтовый сервер. В моем примере все проще, просто две независимые виртуальные машины без служб.

В Veeam BR переходим на закладку Application Groups и выбираем Add App Group. Указываем название нашей группы:


Далее необходимо выбрать виртуальные машины для теста. Порядок, в котором добавлены машины имеет значение, поскольку именно в таком порядке SureBackup будет их запускать. Было бы нелогично сперва запустить почтовый сервер, а уже потом DNS. Для добавления машины необходимо кликнуть на Add VM. Добавить машину можно из файла бэкапа, из реплики, либо из Storage Snapshot:


Справедливости ради стоит заметить, что порядок машин можно изменить кнопками Move Up и Move Down.

Если выбрать машину и нажать кнопку Edit, можно указать список тестов, которые будут выполнены на данной машине. Это роли, скрипты и параметры запуска. В моем случае я хочу убедиться, что машина будет запущена и ответит на пинг, поэтому меня интересует только закладка Startup Options:


Интересующие поля:

1. Maximum allowed boot time — время, которое SureBackup будет дожидаться запуска системы;
2. VM heartbeat is present — будет осуществлена проверка heartbeat от виртуальной машины;
3. VM responds to ping on any network interface — виртуальная машина отвечает на пинг по сетевым интерфейсам.

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

Сохраняем нашу группу, предварительно сверив настройки.

Теперь у нас есть виртуальная лаборатория и группа виртуальных машин, которые необходимо протестировать. Сделать это достаточно просто — необходимо создать задачу SureBackup на закладке Backup & Replication:

1. Как и везде, указываем название задачи и ее описание;
2. На следующей закладке выбираем нашу виртуальную лабораторию;
3. Далее выбираем нашу Application Group;
4. Так же, мы можем привязать к данной задаче непосредственно задачи резервного копирования, если не используются Application Groups;
5. На закладке Settings можно указать email получателя, которому придет отчет о проверке бэкапов;
6. На закладке Schedule указывается расписание, по которому необходимо запускать задачу проверки. Задачи проверки не должны запускаться одновременно с задачами резервного копирования, в противном случае файл бэкапа будет заблокирован и одна из задач будет ждать окончания другой.

В результате у нас появляется раздел SureBackup в Jobs и наша задача тестирования:


Настало время запустить задачу. А я попробую объяснить, как все работает. При запуске задачи мы видим список виртуальных машин для тестирования:


Тестирование виртуальных машин будет идти в порядке, в котором собрана наша Application Group.

1. Производится автоматический запуск Proxy Appliance;

2. Производится публикация первой виртуальной машины с помощью vPower NFS. В этот момент к нашему гипервизору по протоколу NFS подключается дополнительный репозиторий с нашей VM, с него же идет публикация:



3. Данная виртуальная машина запускается из файла бэкапа:


4. Далее Veeam ждет 600 секунд до запуска ОС и начала выполнения тестов, о чем пишет в логах:


Из лога видно, что он обнаружил у виртуальной машины сетевой интерфейс из сети V30 и назначил ей сеть test-vLab1 V30. Далее он проверяет heartbeat и пытается пингануть определившийся адрес:


В суммарном логе можно наблюдать, что тесты по первой машине завершились, выполняется инициализация второй по списку машины из Application Group:

Примечание: сервер Veeam BR автоматически прописывает себе маршруты до маскированных адресов и, в принципе, с него можно к ним подключиться (Вот тот самый адрес 192.168.101.113 из примера про маскарадинг выше):


По окончанию теста, Veeam производит остановку виртуальных машин в обратном порядке и последующую их депубликацию из vSphere:



Получаем заветное письмо на email:


На этом по настройке и работе SureBackup у меня все.

Еще немного про vPower NFS:

1. vPowerNFS используется в основном в таких задачах как Instant VM Recovery и SureBackup;
   
   
2. vPowerNFS подключает NFS хранилище к гипервизору и не отключает его по окончанию работы. Делается это для того, чтобы в следующий раз не приходилось монтировать его вновь и тратить время. Если отключить NFS datastore, в следующий раз он будет вновь примонтирован;
   
   
3. vPowerNFS презентует виртуальную машину из файла бэкапа. Все изменения, которые происходят в дисковой подсистеме машины, переносятся в redo log, который хранятся на vPowerNFS сервере, либо на специально выбранном для этого datastore, оставляя при этом файл бэкапа не изменяемым. Если redo log хранится на сервере vPowerNFS, позаботьтесь о достаточном количестве дискового пространства на данном сервере;

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

Спасибо за внимание. Делайте и проверяйте бэкапы.