По хорошему нужно обновляться. В новых версиях исправления уязвимостей. Например была крупная уязвимость Heartbleed. Если вы хосты 2 года не перезагружали очевидно вы так-же не обновлялись.
Поддержку софт-рейда выпилили по моему в 5 версии — это не энтерпрайзно, низкий уровень надежности, VMWare надоело разбираться с проблемами кастомеров.
Я посмотрел версию которая сейчас актуальна и судя по содержимому скрипта, там появилась поддержка 6-й версии https://raw.githubusercontent.com/lamw/ghettoVCB/master/ghettoVCB.sh
Если хочется самому поправить, то нужно в исходном коде найти проверки версий, и добавить нужную версию. Например:
if [[ "${VER}" == "4" ]] || [[ "${VER}" == "5" ]] ; then
заменить на
if [[ "${VER}" == "4" ]] || [[ "${VER}" == "5" ]] || [[ "${VER}" == "6" ]] ; then
— Инкрементальные не умеет, но по сети гонятся только данные (т.е. thin файл).
— На другой хост нельзя бекапить, только на подмонтированное хранилище (то что можно указывать в путях бекапа утилите, т.е. это должен быть либо NFS сторадж, либо iscsi/das)
— Да, дедупликация на стороне хранилища (нужно какой нибудь ZFS использовать), потому как самый главный недостаток ghettoVCB невозможность делать инкрементальные бекапы, только полные либо thin.
Есть еще ряд недостатков:
— Бэкап делается при помощи снятия снапшота, т.е. изменения VM начинают писаться в дельта-файл, а основной файл диска VM замораживается и копируется на бекап сторадж, после копирования ESX сливает содержимое изменений дельта файла в основной файл VM — и тут могут наблюдаться серьезные тормоза, зависит от вашего железа, размера VM, количества изменений внесенных в дельта файл и сопутствующих параметров. В основном я ставлю бекап на периоды низкой активности (на ночь). В принципе, на сколько я знаю, все виды бекап систем работают именно таким способом, это ограничения API — иными словами ghettoVCB не лучше и не хуже в этом плане коммерческих систем.
— Потеря содержимого оперативной памяти. По идее в VMWare есть механизм работающий через VMWare Tools который позволяет минимизировать последствия (принудительный сброс дисковых буферов операционной системы и т.д., но не всегда корректно работает, нужно это учитывать). В этом плане думаю так же нет отличий от коммерческих систем.
— Думаю хорошей комбинацией является сочетание классического бекапа данных изнутри VM и ghettoVCB
Много лет пользуюсь ghettoVCB. Решение очень надежное, всем однозначно рекомендую. Thin и ротацию бекапов умеет. Есть сжатие (zip) но в реальной работе не имеет смысла — бывает нужно из бекапа поднять виртуалку, а с заархивированной виртуалкой такое не выйдет. Бекапить можно на NFS. Есть возможность прикрутить оповещение по email. Если есть возможность использовать хранилище с дедупликацией — тогда вообще идеальное решение получится. В скрипте нужно допилить возможность бекапа для более высоких версий (достаточно вставить нужные версии ESX), это должно быть просто.
PS
любой бекап VMWare делается при помощи снапшотов
Если хочется самому поправить, то нужно в исходном коде найти проверки версий, и добавить нужную версию. Например:
заменить на
и т.д.
— На другой хост нельзя бекапить, только на подмонтированное хранилище (то что можно указывать в путях бекапа утилите, т.е. это должен быть либо NFS сторадж, либо iscsi/das)
— Да, дедупликация на стороне хранилища (нужно какой нибудь ZFS использовать), потому как самый главный недостаток ghettoVCB невозможность делать инкрементальные бекапы, только полные либо thin.
Есть еще ряд недостатков:
— Бэкап делается при помощи снятия снапшота, т.е. изменения VM начинают писаться в дельта-файл, а основной файл диска VM замораживается и копируется на бекап сторадж, после копирования ESX сливает содержимое изменений дельта файла в основной файл VM — и тут могут наблюдаться серьезные тормоза, зависит от вашего железа, размера VM, количества изменений внесенных в дельта файл и сопутствующих параметров. В основном я ставлю бекап на периоды низкой активности (на ночь). В принципе, на сколько я знаю, все виды бекап систем работают именно таким способом, это ограничения API — иными словами ghettoVCB не лучше и не хуже в этом плане коммерческих систем.
— Потеря содержимого оперативной памяти. По идее в VMWare есть механизм работающий через VMWare Tools который позволяет минимизировать последствия (принудительный сброс дисковых буферов операционной системы и т.д., но не всегда корректно работает, нужно это учитывать). В этом плане думаю так же нет отличий от коммерческих систем.
— Думаю хорошей комбинацией является сочетание классического бекапа данных изнутри VM и ghettoVCB
PS
любой бекап VMWare делается при помощи снапшотов