Application: Bacula v.3.2/v.5.2.
В комплект программного обеспечения VMware Server первой и второй версии входят утилиты "vmware-cmd.bat" и "vmrun.exe", соответственно. Скрипт "vmware-cmd.bat" в комплекте "VMware Server 1" - "обертка" для Perl скрипта; а вот "vmrun.exe" комплекта "VMware Server 2" самостоятельная, насколько я понял, программа, реализующая весьма удобный функционал управления "VMware Server 2" из "командной строки".
Обновляемся до "VMware Server 2". Давно пора, и вообще, мир не стоит на месте, не зря разработчики ставят новые цифры в начале индекса релиза? Лично я просто установил свежую версию "VMware Server 2.0.2" вместо работающей "VMware Server 1.0.8". Не могу сказать, чтобы после этого я преисполнился ощущением полного счастья - без спотыканий в процессе не обошлось - однако, сильно хуже не стало. На всякий случай я оставил часть хостовых машин под "VMWare Server 1", чтобы было с чем сравнить.
Для многих операций с виртуальными машинами поддерживаемыми "VMWare Server 1" (в отличии от "VMWare Server 2") необходимо, чтобы в клиентской машине был установлен набор инструментов "VMWare Server Tools". В нашем случае без этого не обойтись.
Для операций связанных с созданием "бэкапов" для "VMWare Server 2" лучше создать выделенную системную учётную запись, например "vmware", без каких либо особых привилегий в операционной системе и лишить её возможности логина откуда угодно кроме как с локального входа. В локальных политиках безопасности указываем следующие запреты для учётной записи "vmware":
Запретить вход в систему через службу терминалов;
Отказ в доступе к компьютеру из сети;
Отказ во входе в качестве пакетного задания;
Отказать во входе в качестве службы.
Отказ в доступе к компьютеру из сети;
Отказ во входе в качестве пакетного задания;
Отказать во входе в качестве службы.
После необходимо будет дать этой учётной записи необходимые привилегии в консоли управления самого сервера VMWare для запуска/остановки/suspend виртуальных машин и не более того. Использовать её можно будет только для управления виртуальными машинами VMWare сервера.
Копировать файлы виртуальной машины можно встроенной утилитой Windows "copy", но скорость при этом не особо высокая, , да и управляемость процессом отсутствует как класс. В процессе непродолжительных поисков была обнаружено приложение "TeraCopy", сайт разработчиков которого располагается по адресу http://codesector.com/teracopy.php. После ряда тестов (порядка сорока проб на наборах файлов от двадцати до двухсот штук общим объёмом в сто гигабайт) на реальных схемах у меня вышло следующее:
при прочих равных условиях "TeraCopy" быстрее утилиты Windows "copy" процентов на десять-пятнадцать (если я правильно понял, за счёт динамически изменяемого буфера и активного использования асинхронного метода передачи данных).
Последовательность шагов по осуществлению резервного копирования виртуальной машины будет примерно такая:
С помощью утилиты "vmware-cmd.bat" или "vmrun.exe", входящих в комплекты программного обеспечения "VMWare Server" первой или второй версии осуществляем "suspend" (иначе говоря - сохраняем состояние, "замораживаем", "ставим на паузу") гостевой виртуальной машины с целью "сбросить" состояние ее оперативной памяти на дисковые устройства (процедура длится от одной минуты до пяти);
Копируем все файлы виртуальной машины с помощью приложения "TeraCopy" во временную директорию (скорость сильно зависит от производительности дисковой подсистемы, может и за пять минут скопировать виртуальную машину гигабайт эдак на пятьдесят, а может и полчаса копаться);
С помощью утилит "vmware-cmd.bat" и "vmrun.exe" снимаем состояние "suspend";
Осуществляем резервирование на сервер Bacula копии виртуальной машины из временной директории;
Удаляем временную копию.
Копируем все файлы виртуальной машины с помощью приложения "TeraCopy" во временную директорию (скорость сильно зависит от производительности дисковой подсистемы, может и за пять минут скопировать виртуальную машину гигабайт эдак на пятьдесят, а может и полчаса копаться);
С помощью утилит "vmware-cmd.bat" и "vmrun.exe" снимаем состояние "suspend";
Осуществляем резервирование на сервер Bacula копии виртуальной машины из временной директории;
Удаляем временную копию.
Для этого внесём в задание указание на запуск перед его исполнением и после ряда скриптов и команд на стороне клиента.
Для "VMWare Server 1" создадим на стороне клиента скрипт исполняющий непосредственно "заморозку" виртуальной машины и копирование её файлов во временную директорию с именем "c:\custom\backup-vmware-machine0.bat":
# Отключаем вывод скрипта в терминал
@echo off
# "Замораживаем" состояние виртуальной машины
call "c:\program files\vmware\vmware server\vmware-cmd" "c:\var\machine0\machine0-conf.vmx" suspend >> %TEMP%\backup-machine0.log
# Даём VMWare время завершить корректно процедуру "замораживания" (способ извращённый, но иного не предусмотренно)
ping -n 30 localhost > %TEMP%\sleep.txt
# Создаем директорию для временной копии
if not exist "c:\var\tmp" mkdir "c:\var\tmp"
# Копируем всё содержимое директории виртуальной машины
cd "c:\program files\teracopy\"
teracopy.exe Copy "c:\var\machine0\" "c:\var\tmp\" /OverwriteAll /Close
# "Размораживаем" состояние виртуальной машины
call "c:\program files\vmware\vmware server\vmware-cmd" "c:\var\machine0\machine0-conf.vmx" start >> %TEMP%\backup-machine0.log
# Завершаем исполнение скрипта в соответствии с требованиями Bacula
exit 0
@echo off
# "Замораживаем" состояние виртуальной машины
call "c:\program files\vmware\vmware server\vmware-cmd" "c:\var\machine0\machine0-conf.vmx" suspend >> %TEMP%\backup-machine0.log
# Даём VMWare время завершить корректно процедуру "замораживания" (способ извращённый, но иного не предусмотренно)
ping -n 30 localhost > %TEMP%\sleep.txt
# Создаем директорию для временной копии
if not exist "c:\var\tmp" mkdir "c:\var\tmp"
# Копируем всё содержимое директории виртуальной машины
cd "c:\program files\teracopy\"
teracopy.exe Copy "c:\var\machine0\" "c:\var\tmp\" /OverwriteAll /Close
# "Размораживаем" состояние виртуальной машины
call "c:\program files\vmware\vmware server\vmware-cmd" "c:\var\machine0\machine0-conf.vmx" start >> %TEMP%\backup-machine0.log
# Завершаем исполнение скрипта в соответствии с требованиями Bacula
exit 0
Для "VMWare Server 2" создадим на стороне клиента аналогичный по функционалу но несколько иной по содержимому скрипт с таким же именем, как и для предыдущей версии сервера:
# Отключаем вывод скрипта в терминал
@echo off
# "Замораживаем" состояние виртуальной машины
"c:\program files\vmware\vmware server\vmrun.exe" -T server -h "https://127.0.0.1:8333/sdk" -u "vmware" -p "strongPassword" suspend "[datastoreX] machine0/machine0-conf.vmx"
# Создаем директорию для временной копии
if not exist ""c:\var\tmp"" mkdir "c:\var\tmp"
# Копируем всё содержимое директории виртуальной машины
cd "c:\program files\teracopy\"
teracopy.exe Copy "c:\var\machine0\" "c:\var\tmp\" /OverwriteAll /Close
# "Размораживаем" состояние виртуальной машины
"c:\program files\vmware\vmware server\vmrun.exe" -T server -h "https://127.0.0.1:8333/sdk" -u "vmware" -p "strongPassword" start "[datastoreX] machine0/machine0-conf.vmx"
# Завершаем исполнение скрипта в соответствии с требованиями Bacula
exit 0
@echo off
# "Замораживаем" состояние виртуальной машины
"c:\program files\vmware\vmware server\vmrun.exe" -T server -h "https://127.0.0.1:8333/sdk" -u "vmware" -p "strongPassword" suspend "[datastoreX] machine0/machine0-conf.vmx"
# Создаем директорию для временной копии
if not exist ""c:\var\tmp"" mkdir "c:\var\tmp"
# Копируем всё содержимое директории виртуальной машины
cd "c:\program files\teracopy\"
teracopy.exe Copy "c:\var\machine0\" "c:\var\tmp\" /OverwriteAll /Close
# "Размораживаем" состояние виртуальной машины
"c:\program files\vmware\vmware server\vmrun.exe" -T server -h "https://127.0.0.1:8333/sdk" -u "vmware" -p "strongPassword" start "[datastoreX] machine0/machine0-conf.vmx"
# Завершаем исполнение скрипта в соответствии с требованиями Bacula
exit 0
Закрываем скрипты от чтения, не говоря уже о записи, кем бы то ни было, кроме суперпользователя, во избежание. По "хорошему", нужно бы передавать пароль в параметрах вызова скрипта с сервера, чтобы не публиковать его в открытом виде на "хостовой" машине; задача эта несложная, но и не особо важная - любой с правами супер-пользователя всё равно сможет это пароль получить.
Корректируем конфигурацию Bacula:
# cat /etc/bacula/bacula-dir.conf
....
Job {
Name = "job-backup-test.domain.local"
Type = Backup
....
ClientRunBeforeJob = "if exist \"c:\\var\\tmp\" cmd.exe /Q /C rmdir /S /Q \"c:\\var\\tmp\""
ClientRunBeforeJob = "c:/custom/backup-vmware-machine0.bat"
# Удаляем следы жизнедеятельности скриптов резервирования (хотя можно этого и не делать, получится эдакий недельный "бэкап")
ClientRunAfterJob = "if exist \"c:\\var\\tmp\" cmd.exe /Q /C rmdir /S /Q \"c:\\var\\tmp\""
....
Job {
Name = "job-backup-test.domain.local"
Type = Backup
....
ClientRunBeforeJob = "if exist \"c:\\var\\tmp\" cmd.exe /Q /C rmdir /S /Q \"c:\\var\\tmp\""
ClientRunBeforeJob = "c:/custom/backup-vmware-machine0.bat"
# Удаляем следы жизнедеятельности скриптов резервирования (хотя можно этого и не делать, получится эдакий недельный "бэкап")
ClientRunAfterJob = "if exist \"c:\\var\\tmp\" cmd.exe /Q /C rmdir /S /Q \"c:\\var\\tmp\""
....
В описании области резервирования указываем файл "дампа":
# cat /etc/bacula/bacula-dir.conf
....
FileSet {
Name = "file-set-test.domain.local"
Include {
....
File = "c:\var\tmp\"
....
FileSet {
Name = "file-set-test.domain.local"
Include {
....
File = "c:\var\tmp\"
....
Вот и всё.
Вообще-то, для производственных целей больше подходит называемое "мгновенное копирование состояния" с помощью встроенной в сервер функции создания "snapshots". Наверное, так было бы лучше. Но иногда проще и надёжнее, хоть и дольше, копировать файлы виртуальной машины в "замороженном" состоянии, что более или менее гарантирует восстановление таковой без потери данных сервисов в оперативной памяти.
Принцип резервирования массивов информации объёмом более пятидесяти-ста пятидесяти гигабайт, постоянно изменяющейся в рабочем процессе, может быть примерно таким же, как и резервирование виртуальных машин, с предварительным копированием. Дело в том, что Bacula, в соответствии с нашими настройками, после завершения процесса копирования основного объёма проверяет, не было ли за это время каких либо изменений в объектах резервирования. В случае, если найдутся изменённые файлы, они резервируются заново; после снова проверяются объекты и так далее и так далее. В итоге, на данных активного приложения процедура резервирования может затянуться очень надолго (на моей практике Bacula не могла выбраться из процедуры резервирования одного хоста в течении двух с половиной суток).
18 января 2011 в 22:42
19 января 2011 в 10:57
19 января 2011 в 11:06