Резервне копіювання віртуальних машин у XenServer

Одна з приємних особливостей XenServer полягає в тому, що більшість функцій є безкоштовними, але якщо ви хочете функцію "Автоматичний захист та відновлення віртуальних машин", вам слід придбати ліцензію Advanced. Навіть, якщо ви платите за резервні копії на рівні диска, їх недостатньо для більшості робочих навантажень — потрібна функція “миттєвий знімок та повернення до пам'яті”, яка, в свою чергу, є частиною ліцензій “Enterprise” та “Platinum”. Зрозуміло, це не скасовує цінність платних продуктів і рішень таких, як Xen Orchestra, але якщо ваш бюджет дуже обмежений і час простою віртуальних машин при резервному копіюванні не є критичним, можна використовувати bash-скрипт Xen-pocalypse.

де: UUID – це ID монтованого Storage Repository.

В першу чергу необхідно завантажити Xen-pocalypse c GitHub за прямим посиланням і розмістити його на хості XenServer, наприклад, у папці “root”:

Опціонально можна також налаштувати відправлення лога резервного копіювання на пошту за допомогою sendEmail:

Citrix Xen дає можливість використовувати поля, що настроюються (Custom Fields) у властивостях віртуальної машини для їх фільтрації. Xen-pocalypse використовує три типи тегів у Custom Fields, які ми поставимо, перейшовши у властивості віртуальної машини (рис. 1):

резервне

віртуальних

і створимо три поля, що налаштовуються (рис. 2): “BackupTAG”, “Parent”, “Children”.

Теги "Parent" та "Сhildren" опціонально можуть задавати "батьківську" та "дочірні" віртуальні машини. Відключення батьківської ВМ призведе до того, що служба запущена на дочірній ВМ стане недоступною: наприклад, якщо на батьківській ВМ запущено СУБД, а на дочірніх — сервіс, що використовує СУБД. БезТегування parent/children служба на дочірній віртуальній машині буде недоступна двічі: один раз - при резервному копіюванні "дочірньої" віртуальної машини, інший - при резервному копіюванні "батьківської". Можна тегувати “дочірні” віртуальні машини, які будуть відключені та скопійовані перед батьком та будуть включені лише після того, як батьківська ВМ завершить створення резервної копії та буде знову увімкнена. Допускається вказати лише одну батьківську ВМ, тоді імена кількох дочірніх ВМ поділяються пропуском:

Отже, імена "дочірніх" ВМ не повинні містити прогалини.

резервне

машин

та скопіювати отриманий висновок у текстовий файл.

Наступним кроком необхідно створити Storage Repository. Для цього в XenCenter перейдемо:

та скопіюємо UUID (рис. 6). Фактично ваш SR на стороні хоста матиме шлях /var/run/sr-mount/%UUID%, який необхідно буде вказати в конфігураційному файлі Xen-pocalypse. Відкриваємо цей файл для редагування:

  • BackupLocation — вказує шлях, де створюватимуться резервні копії ВМ.
  • ENABLE_COMPRESSION — при включенні дозволяє зменшити обсяг файлу створюваної резервної копії (або XVA-темплейту), але може значно збільшити час створення бекапу і, отже, недоступності ВМ.
  • CHECK_FREE_SPACE - при включенні опції створення резервних копій не призведе до того, що розмір вільного місця на SR стане менше 10Гб.
  • LIST_METHOD — задає режим резервного копіювання, який за умовчанням здійснюється відповідно до тегування ВМ. Можна виставити значення “FILE”, що не рекомендується.
  • DEBUG - дозволяє встановити безліч опцій журналування подій для налагодження. Виведення здійснюється в консоль XenServer, але невідправляється на email.

Найпростіший спосіб перевірити налаштування та працездатність Xen-pocalypse - це виконати консольну команду:

або із зазначенням повного шляху:

Як планувальник можна використовувати cron. Наприклад, додамо в його конфігурацію виконання Xen-pocalypse щоп'ятниці о 23:30:

В результаті виконання скрипту на вмонтованому SR буде створено файл:

Для відновлення створеного XVA-темплейту в XenCenter слід вибрати: