В третьей версии виртуальной инфраструктуры VMware предлагался продукт VCB, VMware Consolidated Backup. Он служил “шлюзом” для внешнего и стороннего ПО резервного копирования, через который это ПО получало доступ к данным виртуальных машин удобным образом.
Притом, для простых случаев VCB был самодостаточен – см. Настройка VCB.
С выходом vSphere были анонсированы vSphere API for Data Protection – программные интерфейсы, встроенные в ESX(i), и выполняющие те же функции. Именно за счет них работают VMware Data Recovery и прочие решения резервного копирования vSphere.
Однако не всем были интересны коммерческие решения, и довольно давно появился проект ghettoVCB, реализовывавший нормальное резервное копирование слегка “на коленке”, но бесплатно.
Сегодня я углядел, что появилась вторая версия этого решения - ghettoVCBg2 - Free alternative for backing up VMs in ESX(i) 3.5 and 4.x (no SSH console required!).
Features
- Support for logging (normal & verbose)
- Single VM backup list across multiple ESX/ESXi host(s)
- Credential-less backups (so long as host(s) are being managed by VIMA/vMA)
- Online back up of VM(s)
- Only valid VMDKs presented to the VM will be backed up
- Support for multiple VMDK backup per VM
- Preserve original powerState of VM(s)
- Ability to shutdown guestOS, initiate backup process and power on VM afterwards with the option of hardpower timeout
- Ensure that snapshot removal process completes prior to continuing the backup process
- VM(s) that initially contain snapshots and Physical RDMs (raw device mapppings) will not be backed up
- Support for VM(s) with Virtual RDMs
- Ability to specify the number of backup rotations per VM
- Output back up VMDKs in ZEROEDTHICK (default behavior), EAGERZEROEDTHICK, 2GB SPARSE or THIN format
- Ouput backup VMDKs using either BUSLOGIC or LSILOGIC adapter type
- Fully support VMDKs stored across multiple datastores
- VM snapshot memory and quiesce options
- Individual VM backup policy (supported on ESX(i) 3.5u2+ & ESX(i) 4.x+)
- Email logs (Experimental Support) NEW!
- Ability to include/exclude specific VMDK(s) per VM (requires individual VM backup policy setup) NEW!
- Independent disk aware (will ignore VMDK) NEW!
- Additional debugging information including dry run execution NEW!
Все прочие подробности по ссылке выше. К сожалению, с ESXi с бесплатной лицензией работать не будет – требуемые API для бесплатной лицензии доступны лишь в read-only режиме.
Читал бегло ту ветку, и одно не понял. Михаил, может вы подскажете?
ОтветитьУдалитьЕсли во время работы скрипта машинка, которая в данный момент бекапится по автоматическому DRS "гульнёт" на другой сервер в кластере - бекап прервётся, вылетит с ошибкой? Или создание снимка (или сам скрипт) как-то зафиксируют ВМ на время бекапа на текущем хосте?
P.S.: А сам скрипт отличный!
если в последней версии ничего не поменялось, то виртуальную машину со снапшотом DRS сам не мигрирует. Я думаю что ничего не поменялось.
ОтветитьУдалитьЯсно, спасибо! Значит стоит бекапы назначать в кроне одновременно на всех хостах, чтоб никто не "увильнул" мигрируя на другой хост.
ОтветитьУдалитьУ меня вопросец возник:
ОтветитьУдалитьДелаю бэкап ghettoVCB2 с памятью. Но судя по файлам всего два: .vmx, .vmdk. То есть файла с дампом памяти нету? Или я ошибаюсь? И еще вопрос, как восстановить бэкап с памятью? с ghettoVCB-restore.sh он тудаже где уже есть виртуалка - восстанавливать не хочет.
такие вопросы правильнее задавать на тамошней ветке форума.
ОтветитьУдалитьМихаил, а вообще есть ли какие нибудь средства резервного копирования ( даже пусть платные ), которые позволяют делать консистентный бэкап ( с паматью ) и восстанавливать его до рабочего состояния?
ОтветитьУдалитьмне такие неизвестны.
ОтветитьУдалитьДа, существует возможность делать бэкапы вместе с памятью, технология описана по ссылке. Осталось только в скрипт оформить:
ОтветитьУдалитьhttp://sysadmins.ru/topic305191.html
Консистентным называется бэкап, у которого консистентна файловая система, т.е. файловые кэши сброшены на диск.
ОтветитьУдалитьС памятью - это немного не то. И не совсем бэкап, поскольку при снапшоте ВМ с дампом памяти сама ВМ замораживается на время от нескольких секунд до нескольких десятков секунд, и перестает обрабатывать входящие соединения. Что неприемлемо в большинстве продуктивных сред.