Бесплатные утилиты для бэкапа с бесплатного ESXI

Как-то появилось у меня несколько персональных проектов, которые требовали относительно много дискового места — около 2TB. Подходящих 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, но:


Другое популярное решение — это open source проект ghettoVCB, но мне он показался несколько сложным для использования, да и документация выглядит немного устаревшей. Про этот проект уже писали здесь на Хабре.

Уверен, что есть и много других вариантов. Будет интересно почитать комментарии опытных админов. Хотя подозреваю, что опытные работают там, где купили нужные лицензии и не парятся…

Здесь можно просто упомянуть:


Если у вас есть опыт использование этих продуктов — поделитесь в комментариях.

Я в конечном итоге решил использовать 2 инструмента:


Xsibackup


До версии 4.4 Xsibackup был на Github, но сейчас (версия 6.0.7) с Github'а Xsibackup убрали, теперь инсталлировать надо с сайта авторов.

В бесплатной версии:


Инструкция установки 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 firewall load

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

» Полный список опций (на английском)

Локально, то есть на одном хосте, всё работает отлично: бэкапы делаются с помощью нативной утилиты ESXI — vmkfstools. Всё быстро, и тонкие диски остаются тонкими. С жёсткими дисками, у меня получилась скорость около 60MB/s

Однако при копирование на удалённый хост я обнаружил, ту же проблему, что и с HP VM Explorer — копируется полный размер VM, даже если диск тонкий, и используется только меньшая часть.

Когда я спросил авторов, в чём причина, то они написали, что для копирования между хостами используется rsync, а он недостаточно «умён», чтобы пропускать невыделенные блоки тонких дисков.

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

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

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

Update: нашёл статью, — по их бенчмаркам выходит, что дело в тормознутом SSH (поверх которого работает rsync), по NFS было бы быстрее.

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

Процесс переноса и бэкапа VMs


Процесс переноса VMs между хостами выглядит у меня так:


Таким же образом пока выглядит и бэкап VM от хостера к себе домой. Для этого у меня дома крутится ESXI — чтобы ovftool мог по сети передавать только полезную нагрузку.

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

Способа делать инкрементальный бэкап я не нашёл.

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

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

Вторая копия — у меня дома, то есть, как и рекомендуют — в физически другом месте. Для восстановления придётся заливать по сети, что существенно медленнее. Но вероятность нужды в этом тоже довольно низкая.

Ovftool


Полное руководство на английском здесь, там же можно и скачать. 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:


Ещё несколько особенностей Ovftool, только при запуске на ESXI:


Примеры использования ovftool:

@SlavikF
10.10.2016 09:55 UTC
Первоисточник