Бесплатные утилиты для бэкапа с бесплатного 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, но:

• При создании бэкапа — с сервера копируется полный размер образа, даже если диск там тонкий (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, у которого есть бесплатная версия: 33hops.com/xsibackup-pro-vmware-esxi-backup.html
• Ovftool

Xsibackup

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

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

• «Горячие» бэкапы, без остановки виртуальных машин. Делается это с помощью снепшота (snapshot)
• Конфигурирование крона (cron) в ESXI
• Отчёты по email
• Ротация бэкапов
• Бэкап на другой ESXI хост. В бесплатной версии — с помощью rsync, заточенного под ESXI. В платной версии ещё есть инкрементальные бэкапы (OneDiff) через создание промежуточных снэпшотов (как по мне — то не очень удачное решение) и дедупликация с помощью их NAS (XSINAS)

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 

mkdir /vmfs/volume1/datastore1/backup

./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 порт.

Полный список опций (на английском): 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.
• Затем с помощью 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 не умеет копировать VM в горячем режиме, то есть требует, чтобы виртуальная машина была выключена. Поэтому — необходимость в Xsibackup выше.

Несколько особенностей работы Ovftool:

• У меня бывало выскакивала ошибка: «The task was canceled by a user». Причина оказалось в том, что 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/"

Автор: SlavikF

Источник