Розбираємося з Veeam SureBackup



Бекапи потрібно перевіряти.

В якості вступу проста історія з бурхливої молодості. Всім знайома ситуація, коли ресурсів немає, а зберігати резервні копії потрібно. У свій час для зберігання резервних копій своїх систем, використовувалося два диска об'ємом по 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;



Після вказівки налаштування Проксі 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 презентує віртуальну машину з файлу бекапа і відразу створює снепшот цієї машини, в який підуть всі подальші зміни, що робиться це для того, щоб файл бекапа не змінювався моменти тестів;
В цілому, налаштування SureBackup за винятком моменту налаштування мереж і маскарадинга не повинна викликати проблем. Вийшло трохи більше, ніж я очікував, але на частині розділити таке не можна.

Дякую за увагу. Робіть і перевіряйте бекапи.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.