Развернуть бэкап на виртуальной машине
Бэкапы виртуальных машин Hyper-V и обычных компьютеров
Хочу поделиться с вами опытом о том, что у меня отняло море времени — о бэкапах виртуальных машин и обычных компьютеров. Как сделать дешево и красиво.
Пожалуй, начну с того, что если вы хотите бэкапы на VMWare, то готовьтесь платить. Бесплатный VMWare — это бесплатно до тех, пока речь не идет о миграциях, бэкапах и тому подобное. На этом месте можно начать бесконечный холивар, но без моего участия. Мои повествования будут только о Hyper-V на Windows Server 2012R2. Хотя часть статьи можно применить и к VMWare, но, вероятно, будут подводные камни.
Бэкапить на Hyper-V мы можем бесплатно, а точнее, теми средствами Windows, за которые мы уже заплатили, приобретая лицензии Windows Server. Для удобства работы с нашими бэкапами (к тому же за это мы тоже заплатили) будем использовать WDS и дедупликацию (может и групповые политики).
1. Бэкап изнутри виртуальных машин
1.1. Бэкап сегодняшнего дня
Насколько мы знаем, любой Windows умеет делать бэкап. Причем, любые настройки бэкапа Windows через интерфейс сводятся, в конечном счете, к фоновому использованию утилиты wbadmin. А что, собственно, умеет wbadmin? А умеет она делать как бэкап образа с системным разделом, так и бэкап отдельных папок. В данной части статьи нас интересует только бэкап образ (системного раздела). Остальное — это специфичные данные виртуальных машин и бэкапить нужно отдельно. Отсюда вывод: Не храните на системном разделе виртуальных машин (и на обычных компьютерах тоже) никакой ценной информации и баз данных, отдельных приложений. MS SQL Server / MS Exchange / «Сервер приложений 1С» и другое ставим только на не системные разделы или на отдельные диски.
Итак, что же нужно, чтобы бэкап отработал? А нужна всего лишь одна команда:
На самом деле, для этой команды нужны особые права, но о них позже. Сейчас важно понять одну вещь. Данная команда делает не просто бэкап. Она делает инкрементальный бэкап. Причем, для серверных и настольных (клиентских) Windows бэкапы формируются разные. И разница заключается в том, что для серверных ОС у нас получатся снимки каждого бэкапа, а вот для настольных — снимок останется всегда только последний. Спросите, а что это за такой инкрементальный бэкап? А «инкрементальный» он остается, потому что бэкапим мы не весь образ, а только изменившуюся часть со времени последнего бэкапа (а значит и меньше трафика и быстрее создается бэкап).
Те, кто сталкивался с аналогичной ситуацией заметят, что бэкап всегда будет «инкрементальный» (полный). Так как бэкап происходит в нашем случае на сетевой диск. То есть для серверной Windows снимки остаются тоже только последние.
1.2. Бэкап с историей предыдущих снимков
На данный момент, мы сделали бэкап образов виртуальных машин. Но это же у нас бэкап снимков только сегодняшнего дня. Завтра он будет совершенно другой… Но что будет, если бэкапить бэкапы? Да и ещё по-настоящему инкрементально. Так и поступим.
Но мне было этого недостаточно и я сделал так:
Скрипт подключает виртуальный диск из сети. После бэкапа подобный же скрипт отключает диск. ОС помнит, что у диска определена буква E. Но не дай бог подсунуть чужой диск с той же буквой E, бэкап отработает уже по полной (не инкрементально и на чужой диск). Имейте это в виду и используйте, букву, ближе к концу алфавита (X, Y, Z)…
Замечу сразу, если бэкап сегодняшний будет производиться параллельно с бэкапом с историей, то получим в итоге бэкап, который невозможно поднять.
Чтобы достать бэкап предыдущих дней можно воспользоваться интерфейсом (GUI) сервера, на котором производятся бэкапы с историей. Более того, все запуски команды wbadmin в консоли Windows знает и помнит. Служба восстановления даст возможность вам выбрать нужный архив в бэкапах с историей.
2. Бэкап файлов vhdx виртуальных машин
Производится легко и непринужденно:
Но с некоторыми особенностями. Эта команда должна выполняться в PowerShell и с предварительным получением списка виртуальных машин в переменную. За подробным примером обращаемся в Google.
Бэкап виртуальных машин в Windows Server 2012 R2 идет с помощью моментальных снимков Hyper-V. Также замечу, что происходят приостановка работы виртуальных машин, если на них ядро Linux или отсутствуют Hyper-V драйвера. Я лично отказался бэкапить виртуальные машины таким способом. Причина в том, что на Windows Server 2012 (не R2) требовалось останавливать виртуальные машины до бекапа. Да и сейчас на Windows Server 2012 R2 приостановки Linux меня не устраивают, когда есть первый неплохой способ бэкапа. (в комментариях к данной статье есть замечание). После очередного обновления в Windows Server 2012 R2 бэкап любых виртуальных машин проходит без приостановок. ОС Linux также можно бэкапить «изнутри» с помощь Dump (CentOS, Ubuntu), но это отдельная тема с puppet’ами и другим ПО в моем случае.
3. Восстановление бэкапа и WDS
А теперь, по-моему мнению, самая полезная часть этой статьи про бэкапы.
WDS — это Windows Deployment Services (службы развертывания Windows) и часть функционала Windows Server 2012R2. Раньше эта служба называлась RIS, но я с ней не сталкивался. Вообщем, суть WDS проста. Прописались в DHCP (автоматически для DHCP Windows Server) в виде отдельных параметров и далее загружаем на компьютер по сети (такая настройка BIOS компьютера для загрузки по сети) через TFTP загрузчик WDS. Далее загрузчик WDS позволяет выбрать из доступных на ней образов «загрузчиков» Windows. Загрузчики бывают разные — это и образы загрузчиков установщика, и PE, и RE образы. Для загрузчика установщика ещё нужны образы самих Windows в WDS, но это в случае, если нужно установить Windows по сети. Нас интересуют RE образы, которые позволяют поднять машину из бэкапа.
Как и что работает в WDS подробно объяснять не буду. Но вот важные заметки:
4. Особенности дедупликации
Можно дедуплицировать работающие виртуальные машины. Можно дедуплицировать бэкапы сегодняшнего дня и можно дедуплицировать бэкапы с историей. Все это дает большой положительный плюс к объему жестких дисков (как для HDD, так и SSD). Но не стоит забывать о некоторых вещах:
5. Групповые политики
Вот тут можно долго и по-разному реализовывать установку скрипта бэкапа с помощью GPO. Но хотелось бы обратить внимание на важные моменты:
Altaro VM Backup: резервное копирование виртуальных машин Hyper-V и VMware
Развертывание виртуальных машин становится общей практикой для компаний всех размеров. По мере внедрения виртуализации и роста популярности облачной модели развиваются и соответствующие средства резервного копирования, охватывая все больше виртуальных сред, операционных систем и приложений. Так как же организовать резервное копирование виртуальной среды на должном уровне? Насколько это сложно?
До сих пор бытует мнение, что при всех своих преимуществах виртуализация существенно осложняет резервное копирование. Возможно, это одна из причин игнорирования компаниями потребности в защите виртуальной среды: по информации зарубежных аналитических агентств, процедуры резервного копирования охватывают менее 70% виртуальных серверов.
На самом деле все не так сложно. Независимо от применяемого гипервизора, например Hyper-V или VMware, подходы к резервному копированию виртуальных машин (ВМ) одинаковы. Оно может выполняться на уровне хост-системы (или, как его еще называют, на уровне гипервизора), либо на уровне ВМ. В настоящее время для резервного копирования виртуальных сред предлагается множество продуктов самого разного класса. Некоторые компании применяют специализированные решения, разработанные именно для конкретного гипервизора, другие предпочитают универсальные продукты.
Процесс восстановления в виртуальной среде имеет свою специфику. Вместо восстановления всего образа ВМ большинство продуктов резервного копирования позволяют восстановить один файл или группу файлов ВМ. А сама резервная копия может храниться и в облаке, в удаленном ЦОД. Такой способ становится все более популярным. В этом случае данные обычно копируются локально, а затем реплицируются в облако (Cloud Backup). Резервирование в облаке не решает все проблемы локальной защиты и обеспечения высокой готовности, но защищает от аварий (DR).
Новые возможности продуктов резервного копирования помогают надежнее и быстрее восстанавливать виртуальные машины, приложения и данные в случае отказа, найти необходимый баланс между допустимым временем восстановления информации (Recovery Time Objective, RTO), допустимой потерей информации (Recovery Point Objective, RPO) и стоимостью решения. Ниже пойдет речь об одном из таких решений.
Резервное копирование – это просто
Altaro VM Backup — простое в использовании решение для резервного копирования с интуитивно понятным интерфейсом и несложной настройкой. Более 30 тыс. компаний применяют его для надежного хранения и восстановления виртуальных машин Hyper-V и VMware. Как свидетельствуют отзывы пользователей, Altaro VM Backup устанавливается в разы быстрее конкурентных решений и отличается очень удобным и понятным интерфейсом. Это ПО поддерживает резервное копирование и восстановление ВМ между разными серверами и разные типы хранилищ для резервных копий – локальные (DAS), внешние (NAS/SAN) и облачные (Cloud Backup). 
Нацелено программное обеспечение Altaro, известное ранее под названием Altaro Hyper-V Backup, на компании сегмента SMB. Именно поэтому разработчики постарались сделать его максимально простым и интуитивно понятным, но при этом обладающим всеми необходимыми малому и среднему бизнесу средствами. Выпущенная в прошлом году шестая версия продукта поддерживает резервное копирования ВМ и в среде Microsoft Hyper-V, и в среде VMware vSphere, поэтому и называется он теперь Altaro VM Backup.
Перечислим его основные особенности:
Что нового в Altaro VM Backup 6.0?
Кроме поддержки VMware версия 6.0 предлагает следующие новые средства:
Варианты общения со службой поддержки
Что включает в себя Altaro VM Backup?
В состав Altaro VM Backup входит четыре ключевых компонента:
Процесс инсталляции
Инсталлировать Altaro VM Backup не просто, а очень просто. Достаточно запустить установщик, пару раз нажать «Далее», и все. Никаких дополнительных компонентов инсталлировать не требуется. После завершения процесса и запуска Altaro VM Backup устанавливается соединение с экземпляром программы на одном из серверов, например, localhost. Нужный для этого порт (35107) в интерфейсе уже прописан.
Следующий шаг – соединение с
Выберем для примера хост ESXi. Для соединения потребуется имя, имя хоста, аккаунт и пароль. Порты 443 и 902 (vSphere VDDK) должны быть открыты. После того как соединение с хостом установлено, нужно выбрать место для резервирования данных – локальное (USB, eSATA, iSCSI) или сетевое устройство. Конечно, для надежности предпочтительнее хранить резервные копии на съемном носителе или на другой площадке, например, настроить репликацию по глобальной сети. Хранимые данные ВМ шифруются.
Места хранения резервных копий
Консоль мониторинга показывает информацию по заданиям резервного копирования, резервированию на сторонней площадке и хранилищу резервных копий.
Для более чёткого понимания опишем процесс инсталляции и запуска продукта по шагам.
Вот, собственно, и всё. От начала инсталляции до запуска процесса резервирования обычно проходит минут десять.
Начальное создание резервной копии может потребовать немало времени и создать нагрузку на сеть. Поэтому можно просто скопировать данные на съемный носитель и перевести их на другую площадку, а последующие копии передавать по глобальной сети – этот процесс уже не будет таким ресурсоемким. Такой вариант продукт поддерживает.
Добавление нового правила хранения резервной копии.
Далее нужно назначить для ВМ место хранения. Это делается простым перетаскиванием ВМ в графическом интерфейсе на целевое хранилище и нажатием кнопки «Сохранить изменения». Осталось создать резервную копию. Выберите ВМ и нажмите «Резервировать». Теперь можно настроить расписание копирования.
Создание консистентных копий приложений
Altaro поддерживает создание консистентных копий приложений, используя технологию Microsoft VSS. Это означает, что после восстановления ВМ приложение с поддержкой VSS не окажется «испорченным». Для работы с логами приложений типа Exchange Server или SQL нужно установить Altaro VM Tools. Это можно сделать удаленно с помощью консоли управления.
Проверка резервных копий
Как убедиться в том, что из резервной копии можно будет действительно восстановиться? Об этом нередко просто забывают. В Altaro VM Backup предлагается два метода верификации – по контрольным суммам и путем фактического восстановления ВМ. Первый, Backup Verification, позволяет просто убедиться в целостности данных на носителе. Второй, Sandbox Restore, позволит вам спать спокойно. Оба варианта можно планировать для автоматизации данного процесса.
Окно отчетов показывает статус резервной копии, результат верификации и заданий восстановления
Настройка и планирование Sandbox Restore
Sandbox Restore восстанавливает ВМ под временным именем. Администратор может запустить ее и убедиться, что она загружается. На работу других ВМ это не повлияет.
Восстановление файлов
Восстанавливать файлы можно тремя способами:
Восстановление из Exchange на уровне элементов
Второй способ очень прост и выполняется по шагам. Выбирается ВМ, виртуальный жесткий диск и файлы для восстановления. Altaro VM Backup восстанавливает файлы в специальную папку, после чего остается скопировать их в ВМ.
Непосредственно с консоли Altaro можно выполнять гранулярное восстановление, например, восстановить файл или почтовый ящик
Панель управления Altaro VM Backup в наглядной форме показывает всю необходимую информацию
Планирование резервного копирования
Выводы
Какую технологию или продукт резервного копирования ВМ, какой подход лучше всего использовать в конкретных обстоятельствах? На что следует обращать внимание в первую очередь? На этот вопрос нет однозначного ответа – все зависит от корпоративной политики, процедур и требований бизнеса, размера компании и других факторов. Altaro VM Backup, определенно, заслуживает того, чтобы познакомиться с ним поближе. Попробуйте!
Создание резервных копий виртуальных машин
Многие предприятия, а также домашние пользователи все чаще и чаще используют виртуальные машины для выполнения различного рода задач и повышения эффективности своей деятельности. Если раньше виртуальные машины применялись, в основном, энтузиастами, то теперь качество настольных и серверных платформ виртуализации позволило использовать их профессионалам в крупных масштабах. Возможность запуска нескольких виртуальных систем на одном физическом компьютере имеет множество достоинств, среди которых: экономия на аппаратном обеспечении, упрощение обслуживания и снижение затрат на электроэнергию в крупных датацентрах. Кроме того, важным достоинством виртуальных машин является их простая переносимость на другую физическую платформу и простая процедура их резервного копирования. Но также как и обычные операционные системы, виртуальные среды требуют высокого внимания к созданию резервных копий критически важных данных. При работе виртуальных машин в производственной среде предприятия многие компании планируют целые стратегии по архивации и восстановлению виртуальной инфраструктуры после сбоев, которые получили название Disaster Recovery.
Многие поставщики коммерческих платформ виртуализации предлагают корпоративным пользователям встроенные средства архивации виртуальных машин, такие как VMware Consolidated Backup (VCB) для платформы ESX Server. Однако в секторе SMB (Small and Medium Business), где число используемых виртуальных машин невелико, практически отсутствуют предоставляемые производителем платформ средства резервного копирования. Вследствие этого, небольшим компаниям приходится привлекать системных администраторов для написания различных скриптов, а также использования стандартных утилит операционных систем, обеспечивающих архивацию и восстановление файлов и папок с жизненно важными данными.
Общие сведения о резервном копировании данных
Одновременно с процессом планирования виртуальной инфраструктуры необходимо также инициировать процесс по разработке плана архивации и восстановления после сбоев (Disaster Recovery Plan). Прежде всего, нужно выделить наиболее критические элементы ИТ-инфраструктуры, которые потенциально подвержены повреждениям со стороны внутренних и внешних источников, таких как отключение электропитания, неисправности жестких дисков, вирусная угроза и прочие. После этого, необходимо продумать частоту резервного копирования виртуальных машин различных категорий в зависимости от степени критичности. Виртуальные продакшен-сервера компании, которые работают в режиме полной публичной доступности, должны архивироваться довольно часто и регулярно и обладать свойством быстрой восстанавливаемости в случае сбоя. Внутренние сервера организации, не требующие столь высокого внимания и быстрого восстановления, могут архивироваться реже, с бoльшим временем восстановления. Затем нужно определить, какие устройства хранения будут использоваться для архивации (IDE или SCSI диски других серверов, устройства SAN и т. п.).
Для того чтобы пояснить, чем отличаются эти типы архивации, приведем пример комбинирования видов резервного копирования. При использовании полной и добавочной архивации существенно уменьшается время резервного копирования, однако увеличивается время восстановления. К примеру, если мы сделали полную архивацию в понедельник и ежедневно накатывали добавочную архивацию, а в пятницу система была повреждена, нам необходимо будет восстановить полную архивную копию понедельника и последовательно все добавочные копии до пятницы, что займет весьма длительное время. Комбинирование полной и разностной активации, наоборот, требует большее время на проведение архивации, однако меньшее на восстановление, поскольку потребуется восстановить только полную архивную копию данных понедельника и накатить на нее разностный архив пятницы.
Это, конечно же, не все типы архивации, которые могут быть использованы при резервном копировании данных, однако перечисленные виды — одни из самых часто используемых. Очевидно, что для серверов с высокой критичностью к времени восстановления целесообразнее использовать разностную архивацию в комбинации с полной, нежели добавочную. Первая подойдет для внешних серверов организации, вторая — для внутренних, которым позволительно большее время простоя.
Поскольку, в основном, виртуальная машина представляет собой папку с файлами, то можно применять встроенные средства резервного копирования хостовой операционной системы, в случае если используется платформа виртуализации поверх хостовой системы такая как, например Microsoft Virtual Server или VMware Server. В Microsoft Windows для этих целей можно применять утилиту ntbackup. При использовании bare-metal платформ (класса «голое железо»), таких как ESX Server или Virtual Iron, необходимо воспользоваться средствами производителя системы виртуализации или продуктами сторонних разработчиков.
Кроме того, резервное копирование виртуальных машин может осуществляться путем создания образов гостевых систем с помощью программного обеспечения, такого как Acronis True Image. Стоит отметить также, что бывают ситуации, когда необходимо осуществить архивацию не всей виртуальной машины, а некоторых данных в гостевой системе. В этом случае, при написании пакетных сценариев архивации можно использовать утилиты для монтирования виртуальных дисков в хостовую систему. Для платформ VMware такой утилитой является приложение VMware Disk Mount.
Архивация и восстановление виртуальных машин на платформе VMware ESX Server
Создание резервных копий виртуальных машин с помощью VCB происходит путем создания мгновенных снимков виртуальных машин без остановки их работы. VCB поддерживает также сети хранения SAN. Если виртуальные машины расположены на устройстве хранения SAN, процедура резервного копирования выглядит следующим образом:
Созданные в процессе работы снимки состояний виртуальных машин с помощью агента, расположенного на прокси-сервере VCB сохраняются на резервном носителе, откуда затем могут быть восстановлены в случае сбоя запущенной гостевой системы или порчи оборудования. В этом случае, бэкап-агент имеет прямой доступ к логическим единицам LUN (Logical Unit Number) в устройствах SAN. Для сетей SAN средства VCB поддерживают протокол Fibre Channel, а также ленточные носители для сохранения архивных копий. VCB тесно использует возможности VMware Tools, запущенных внутри гостевой системы, для создания резервных копий данных гостевой ОС.
В процессе создания резервных копий средства VCB используют компоненты виртуальной инфраструктуры, представленные ниже: 
Подводя итоги можно сказать, что VMware Consolidated Backup представляет собой мощное средство для создания резервных копий виртуальных машин и дает возможность применять стандартное ПО резервного копирования, используемое в организации для создания архивных копий данных.
Резервное копирование с помощью Vizioncore esxRanger
Продукт esxRanger компании Vizioncore, контролируемой сейчас компанией Quest Software, на данный момент является одним из самых популярных решений для создания архивных копий виртуальных машин на платформе ESX Server. esxRanger не требует установки никаких дополнительных агентов на серверы ESX и создает архивные копии виртуальных машин с одного сервера либо группы серверов за счет интеграции с продуктом Virtual Center. Процесс создания резервных копий происходит на одном Windows-сервере, откуда архивные образы виртуальных систем могут быть сохранены на различных устройствах хранения в производственной среде организации.
esxRanger обладает как GUI-интерфейсом, так и интерфейсом командной строки, что позволяет использовать обычный планировщик задач Windows для запуска работ резервного копирования по расписанию, что отменяет необходимость написания дополнительных скриптов. Главное окно продукта esxRanger представлено ниже:
Подключившись к VMware Virtual Center, при наличии соответствующих разрешений, можно выбрать отдельные виртуальные машины серверов датацентра для резервного копирования. Копируемые образы автоматически сжимаются при архивировании и распаковываются при восстановлении, что позволяет экономить время системным администраторам.
esxRanger интегрируется с VMware Consolidated Backup при использовании в сетях хранения данных SAN и позволяет создавать полные или дифференциальные копии виртуальных машин, а также отдельных файлов и папок в гостевых ОС Windows. Кроме того, в процессе резервного копирования esxRanger собирает различную информацию о метриках архивации (таких как время, затраченное на архивацию и восстановление), хранит ее в базе данных и позволяет использовать ее для построения трендов стратегии Disaster Recovery. В дополнение к этому, esxRanger имеет механизм политик, которые позволяют строить стратегию архивации данных на основе шаблонов и интегрировать его с другими компонентами ИТ-инфраструктуры организации, максимально снизив загрузку системных администраторов.
В целом, esxRanger является удобным, надежным и простым в использовании средством создания архивных копий виртуальных машин в Virtual Infrastructure 3, которое обладает возможностями интеграции с VMware Consolidated Backup, что позволяет использовать его в сетях хранения данных SAN компаний любого масштаба.
Создание резервных копий виртуальных машин на платформе Microsoft Virtual Server
Для того чтобы произвести архивацию запущенных виртуальных машин на платформе Virtual Server можно использовать ее COM-интерфейс, написав сценарий, к примеру, с помощью Visual Basic Scripting (vbs). При создании резервной копии виртуальной машины необходимо сначала перевести ее в сохраненное состояние (Saved State), затем скопировать ее файлы в заданное место и, после этого, снова запустить ее. Ниже приведен пример скрипта на vbs, который делает эти необходимые действия для копирования одной виртуальной машины. Его можно запускать по расписанию с помощью стандартного планировщика задач Windows. ‘ backupvm.vbs ‘ автор: John Savill ‘ использование : backupvm.vbs Option Explicit On Error Resume Next Dim objFSO, objVirtualServer, objVM, objSaveTask, objVHD ‘Соединение с объектом файловая система set objFSO=CreateObject(«Scripting.FileSystemObject») ‘Соединение с Virtual Server set objVirtualServer = CreateObject(«VirtualServer.Application») ‘Поиск виртуальной машины set objVM = objVirtualServer.FindVirtualMachine(WScript.Arguments(0)) ‘Сохранение состояния виртуальной машины set objSaveTask = objVM.Save ‘Пауза для выполнения операции сохранения while not objSaveTask.isComplete WScript.Sleep 1000 wend ‘Копирование виртуальных дисков и UNDO-дисков for each objVHD in objVM.HardDiskConnections If objFSO.FileExists(objVHD.HardDisk.file) Then ‘Wscript.Echo objVHD.HardDisk.file & » » & WScript.Arguments(1) objFSO.CopyFile objVHD.HardDisk.file, WScript.Arguments(1) End If If objFSO.FileExists(objVHD.undoHardDisk.file) Then ‘Wscript.Echo objVHD.undoHardDisk.file & » » & WScript.Arguments(1) objFSO.CopyFile objVHD.undoHardDisk.file, WScript.Arguments(1) End If Next ‘Копирование vsv и vmc файлов objFSO.CopyFile objVM.File, WScript.Arguments(1) objFSO.CopyFile objVM.SavedStateFilePath, WScript.Arguments(1) ‘Запуск виртуальной машины objVM.Startup
Этот скрипт необходимо использовать следующим образом:
C: emp>cscript backupvm.vbs
Нужно отметить, что компания Microsoft официально не поддерживает такой процесс создания резервных копий, поскольку целостность виртуальной машины, скопированной в сохраненном состоянии, может быть нарушена из-за того, что часть ее памяти не сохраняется в этом случае в файлах vsv и vhd.
Использование службы Volume Shadow Service
Поддержка служб VSS появилась в недавно вышедшем релизе Virtual Server 2005 R2 SP1. Использование служб теневого копирования в Virtual Server предполагает создание резервных копий запущенных виртуальных машин за счет создания образов, что должно существенно упростить и ускорить процедуру резервного копирования и восстановления. Однако недостаточно, чтобы программное обеспечение для резервного копирования поддерживало VSS, необходимо также, чтобы оно поддерживало еще и новый Virtual Server VSS Writer Service (VS Writer), обнаружить поддержку которого, на данный момент, не удалось ни у одной из систем архивации. В соответствии с информацией Microsoft, средства резервного копирования могут использовать VS Writer для архивации и восстановления виртуальных машин следующим образом: они нотифицируют Virtual Server о том, что процесс архивации начался, Virtual Server отвечает на это созданием снимка виртуальной машины, после чего начинается процесс копирования. На данный момент утилита NTBackup также не поддерживает этот механизм.
Резервное копирование виртуальных машин Xen
Компания XenSource, занимающаяся поддержкой Open-Source проекта Xen, а также распространением коммерческой платформы виртуализации XenEnterprise, предлагает не так много вариантов архивации виртуальных машин на платформе Xen. Один из них приведен ниже с использованием устройств хранения данных в файловой системе NFS (Network File System).
Заключение
Составление и реализация плана резервному копированию и восстановлению после сбоев (Disaster Recover Plan) наиболее важных серверов и рабочих станций организации является необходимой составляющей ее деятельности. Виртуальные машины, даже больше чем физические, требуют высокого внимания к архивации данных, поскольку обычно несколько виртуальных систем консолидировано на одном физическом хосте. Ведущие производители платформ виртуализации стремятся к тому, чтобы предоставить мощные и удобные средства резервного копирования, однако на данный момент это удалось только компании VMware. Стратегию резервного копирования можно проводить двумя способами: один из самых простых путей, делать это в рамках стандартной стратегии по архивации данных в ИТ-инфраструктуре компании, за счет установки в гостевых системах агентов резервного копирования и создания образов. Другой, более удобный и быстрый путь — использование встроенных средств платформ, таких как VMware Consolidated Backup или написание скриптов системными администраторами. В любом случае, никогда нельзя забывать, что отказ оборудования или иные форс-мажорные обстоятельства не должны существенно влиять на критически важную деятельность компании.