Безкоштовні утиліти для бекапа з безкоштовного ESXI

Як з'явилося у мене кілька персональних проектів, які вимагали відносно багато дискового місця — близько 2 ТБ. Відповідних VPS не знайшлося (мало хто пропонує багато HDD місця), тому я взяв виділений сервер у OVH, поставив там ESXI 5.5 з безкоштовною ліцензією і все працювало.

Через деякий час, з развитем проектів, я став налаштовувати адмінських фішки — моніторинг, бекап, і з'ясував, що виявляється сервер, в якому мені обіцяли Soft RAID, та на який хостер (OVH) накотив свій образ ESXI — без RAID! Тобто просто 2 диска. Ну так, тепер я знаю, що ESXI не підтримує Soft RAID, тільки Hard. Стало незатишно. Та й 2TB стало не вистачати. Загалом взяв я собі сервер побільше, з апаратним RAID і поставив туди ESXI 6.0.

І виникло дві задачі, рішення яких я тут опишу:
  1. Перенести віртуальні машини (деякі з яких близько 1TB) з одного сервера на інший з мінімальним оффлайном
  2. Робити регулярні бекапи
Скажу відразу, що обидві ці проблеми легко вирішуються, якщо є хоча б мінімальна платна ліцензія ESXI. Справа в тому, що «рідний» Backup API у безкоштовній версії ESXI вимкнений. Тому доводиться знаходити інші шляхи.

З платною ліцензією є варіант міграції через vCenter. Ще є безкоштовна версія Veeam Backup, яка дозволяє робити бекапи і переносити віртуальні машини з однієї системи на іншу і при цьому не потрібно зупиняти. Але з безкоштовною ліцензією ESXI, поточна версія — Veeam 9 — не працює взагалі.

Ще є рішення від HP — VM Explorer, у якого є безкоштовний Free Edition.

VM Explorer 6.2 вміє працювати з free ESXI, але:
  • створення бекапу — з сервера копіюється повний розмір образу, навіть якщо диск там тонкий (thin). Тобто, якщо диск у віртуальної машини на 500GB, а там записано тільки 50GB, то будуть копіюватися 500GB. І так — щоразу. Режим інкрементального бекапу (тільки на локальний комп'ютер) є в платній версії, я його не тестував — на знаю, наскільки воно ефективно.
  • Безкоштовна ліцензія дозволяє робити бекап тільки на локальні диски. Тобто, щоб скопіювати на інший ESXI хост потрібна вже платна ліцензія.
  • У безкоштовної версії немає планувальника, тобто запускати бекапи потрібно вручну.
Інше популярне рішення — це open source проект ghettoVCB github.com/lamw/ghettoVCB, але мені він здався трохи складною для використання, так і документація виглядає трохи застарілою:
communities.vmware.com/docs/DOC-8760
Про цей проект вже писали тут на Хабре: habrahabr.ru/post/265043

Впевнений, що є й багато інших варіантів. Буде цікаво почитати коментарі досвідчених адмінів. Хоча підозрюю, що досвідчені працюють там, де купили потрібні ліцензії і не паряться…
Тут можна просто згадати:
  • Nakivo, у якій у безкоштовній версії обмеження на 2 VM.
  • Unitrends, у якій у безкоштовній версії обмеження — 1TB.
  • Thinware
Якщо у вас є досвід використання цих продуктів — поділіться в коментарях.

Я в кінцевому підсумку вирішив використовувати 2 інструменту:


Xsibackup

До версії 4.4 Xsibackup був на Github, але зараз (версія 6.0.7) з Github'а Xsibackup прибрали, тепер треба інсталювати з сайту авторів.

У безкоштовної версії:
  • «Гарячі» бекапи, без зупинки віртуальних машин. Робиться це з допомогою снепшота (snapshot)
  • Конфігурування крона (cron) в ESXI
  • Звіти по email
  • Ротація бекапів
  • Бекап на інший ESXI хост. У безкоштовної версії — з допомогою rsync, заточеного під ESXI. У платній версії ще є инкрементальные бекапи (OneDiff) через створення проміжних снэпшотов (як по мені — то не дуже вдале рішення) і дедупликация з допомогою їх NAS (XSINAS
Інструкція установки XsibackupЦя ж інструкція на англійській — 33hops.com/blog_xsibackup-quickstart.html

Інсталюється Xsibackup на ESXI хост, з якого треба робити бекапи.
На ESXI повинен бути включена служба SSH.
Реєструєтесь на сайті авторів — Download xsibackup — 33hops.com/xsibackup-vmware-esxi-backup.html
Вам на email прийде безкоштовний ключ і скрипт для інсталяції на ESXI:
cd /vmfs/volumes/datastore1/xsi-dir 2>/dev/null || mkdir /vmfs/volumes/datastore1/xsi-dir && \
cd /vmfs/volumes/datastore1/xsi-dir && \
esxcli network firewall unload && \
wget http://a.33hops.com/downloads/?key=64cG...secretKey -O xsibackup.zip && \
unzip -o xsibackup.zip || cat xsibackup.zip && echo "" && \
chmod 0700 xsibackup* && \
rm -rf xsibackup.zip && \
esxcli network load firewall 

secretKey у вас буде свій.
Якщо datastore у вас називається по іншому — то треба прописати свій шлях.

Побачивши wget, хтось може похитати головою, і сказати, що ставити чужий софт на ESXI хост — це несекьюрно і т. д. Однак при будь-якому бекапі, ви будете віддавати root пароль програмі для бекапа, тобто комусь довіряти ви будете в будь-якому випадку. При локальному копіюванні Xsibackup використовує тільки shell сценарії, які можна подивитися і перевірити…

Потім створюєте теку, куди будемо складати бекапи — локально, або на іншому сервері:
mkdir /vmfs/volume1/datastore1/backup

Якщо копіювати бекапи буде між хостами, то ділимося SSH ключами:
./xsibackup --link-srv=[second.esxi.system.ip]

Якщо хочемо, щоб був бекапи запускалися через крон, то:
./xsibackup --install-cron

Тестуємо, що все працює локально:
./xsibackup --backup-point=/vmfs/volumes/datastore1/backup --backup-type=running --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.yourserver.com --smtp-port=25 --smtp-usr=username --smtp-pwd=password --test-mode=true

Щоб протестувати роботу між хостами, змінюємо:
--backup-point="IP-OF-ESXI:22:/vmfs/volumes/datastore1", де 22 - це SSH порт.

Якщо SMTP вимагає TLS, то підтримується --smtp-sec=TLS

Повний список опцій (англійською): 33hops.com/xsibackup-help-man-page.html

Локально, тобто на одному хості, все працює відмінно: бекапи робляться з допомогою нативної утиліти ESXI — vmkfstools. Все швидко, і тонкі диски залишаються тонкими. З жорсткими дисками, у мене вийшла швидкість близько 60MB/s

Однак при копіювання на віддалений хост я виявив, ту ж проблему, що і з HP VM Explorer — копіюється повний розмір VM, навіть якщо диск тонкий, і використовується тільки менша частина.
Коли я запитав авторів, в чому причина, то вони написали, що для копіювання між хостами використовується rsync, а він недостатньо «розумний», щоб пропускати невиділені блоки тонких дисків.

При тестуванні, я виявив, що при повторних бэкапах, rsync практично практично не скорочує час копіювання по мережі знову йде повний розмір VM.

Автори написали, що в планах у них запив власну утиліту замість rsync, яка буде набагато швидше. Планують випустити до кінця року.

У моєму випадку, хостер гарантує швидкість мережі у 250Mb/s (~31MB/s), але реально між двома хостами в одному датацентрі бекап у мене працював на 10-20MB/s. Не знаю в чому тут справа, — гальмує це мережа, rsync або що ще, — але процес розтягується занадто надовго.

Радує, що в результаті диски таки залишаються тонкими.

Процес перенесення і бекапа VMs

Процес перенесення VMs між хостами виглядає так:
  • Спочатку, я роблю локальні бекапи з допомогою Xsibackup.
  • Реєструю нову VM — копію з попереднього кроку.
  • Необов'язково: Можна «почистити» VM від видалених файлів командою: vmkfstools --punchzero VMname.vmdk — вказувати основний файл, а не той, який -flat.
  • Потім за допомогою Ovftool (див. нижче) копіюю на інший хост. Ovftool вміє слати тонкі диски так, що відсилається тільки використовувана частина.
  • Після цього VM на першому хості вимикається, а новому — запускається.


Таким же чином виглядає і бекап VM від хостера до себе додому. Для цього у мене вдома крутиться ESXI — щоб ovftool міг передавати по мережі тільки корисну навантаження.

форумах пишуть, що начебто є спосіб копіювати файли на NFS з опцією sparse так, щоб передавати тільки наявні дані, але я поки ще не розібрався.

Способи робити інкрементальний бекап я не знайшов.

Поки я це все роблю вручну з консолі — переношу на інший хост, роблю перший бекап, але з часом думаю все налаштувати через крон. Може пізніше допишу тут пару абзаців про те, як налаштовувати крон. Оригінальні інструкції ось тут: 33hops.com/xsibackup-cron-how-to.html

Таким чином зараз у мене перша копія лежить поруч, на тому ж сервері, і доступна для досить швидкого відновлення.
Друга копія — у мене вдома, тобто, як і рекомендуют — у фізично іншому місці. Для відновлення доведеться заливати по мережі, що істотно повільніше. Але ймовірність потреби в цьому теж досить низька.

Ovftool

Повне керівництво англійською тут: www.vmware.com/support/developer/ovf
Там же можна і скачати.
Ovftool можна ставити до себе на будь-який комп'ютер, і управляти гіпервізором з нього.
А можна і поставити прямо на ESXI хост, хоча це і не підтримувана можливість.
Інсталяція Ovftool на ESXIзагалом, процес такий: спочатку Ovftool ставиться на Linux x64 (я робив на Ubuntu 16), а потім-файли переносяться на ESXI хост.

Ось по кроках:
  • Зареєструватися з VMware і завантажуєте «VMware OVF Tool for Linux 64-bit»

  • Запускаєте скачаний файл на Linux і потім копіюєте отримані файли на ESXI:
    sudo /bin/sh VMware-ovftool-4.1.0-2459827-lin.x86_64.bundle
    scp -r /usr/lib/vmware-ovftool/ root@esx.com:/vmfs/volumes/datastore1
    
  • Потім вже на самому хості, необхідно відредагувати один файл — /vmfs/volumes/datastore1/vmware-ovftool/ovftool і в ньому замінити #!/bin/bash #!/bin/sh

Ovftool не вміє копіювати VM в гарячому режимі, тобто вимагає, щоб віртуальна машина була вимкнена. Тому — необхідність в Xsibackup вище.

Кілька особливостей роботи Ovftool:
  • У мене бувало вискакувала помилки: «The task was canceled by a user» або «Error: vim.fault.FileNotFound». Причина обох помилок виявилося в тому, що CDROM на оригінальній машині вказував на ISO, якого не було на цільовому хості. Спробуйте здогадатися про це за текстом помилки… Вирішилося видаленням CDROM пристрою (воно використовувалося тільки для інсталяції OS).
  • Я сам не перевіряв, але начебто ovftool не зберігає snapshots.
Ще кілька особливостей Ovftool, лише при запуску на ESXI:
  • Хоч ovftool запускається локально, шлях до хосту треба прописувати повністю, разом з користувачем і паролем.
  • Не вміє інтерактивно читати пароль з консолі, а вимагає, щоб він був переданий параметр у командному рядку.
  • В паролі можна використовувати тільки букви, цифри і `-`. При спробі використовувати інші символи, типу ` # ` пароль не приймався.


Приклад запуску ovftool:
ovftool -ds=datastore1 -dm=thin "vi://root:password@esx1.com/vmName" "vi://root:password@esx2.com/"

Джерело: Хабрахабр

0 коментарів

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