Выполняется слияние hyper v что это

Как остановить зависшую виртуальную машину в Hyper-V?

06.09.2022

itpro

Hyper-V, PowerShell, Windows Server 2016, Windows Server 2019

комментариев 5

Если ваша виртуальная машина, запущенная на хосте Hyper-V зависла по каким-то причинам, перестала отвечать, и не реагирует на кнопки включения, выключения, перезагрузки в консоли Hyper-V Manager, единственный быстрый способ принудительно остановить такую машину — завершить процесс этой ВМ в хостовой ОС. Вы можете принудительно перезапустить конкретную ВМ в Hyper-V на Windows Server 2022/2019/2016 (или бесплатного Hyper-V Server) без перезагрузки всего сервера и запущенных на нем виртуальных машин (полезно, если у вас нет HA кластера Hyper-V и Live-Migration).

Виртуальная машина Hyper-V зависла в статусе Stopping или Starting

Администраторы Hyper-V периодически сталкиваются с ситуациями, когда что одна из ВМ на хосте Hyper-V зависает в состоянии Stopping (Stopping-Critical), Starting (Starting 10%) или Backing up.

При этом гостевая ОС перестаёт отвечать, и кнопки “Turn Off”,” Shut Down” и” Reset” вв консоли Hyper-V Manager становиться недоступны или при нажатии возвращают ошибку:

Failed to change state The operation cannot be performed while the object is in its current state

Если ваш хост Hyper-V не показывает список зарегистрированных виртуальных машин в консоли Hyper-V Manager и возвращает ошибку “Connecting to Virtual Machine Management service”, вам нужно перезапустить процесс vmms.exe (служба Hyper-V Virtual Machine Management). Это безопасная операция, которая не прервет работу запушенных виртуальных машин. Проще всего перезапустить процесс службы vmms через консоль services.msc или PowerShell командой:

Как завершите процесс зависшей виртуальной машины Hyper-V?

Чтобы принудительно выключить/ перезапустить зависшую виртуальную машину без перезагрузки всего хостового сервера Hyper-V, нужно завершить ее рабочий процесс на гостевой ОС. Все ВМ на хосте Hyper-V запускаются с помощью процесса vmwp.exe (Virtual Machine Worker Process). Для поиска конкретного PID процесса нужно узнать GUID виртуальной машины.

Вы можете найти GUID ВМ в консоли управления Hyper-V Manager. Откройте настройки сервера (Hyper-V Settings). В разделе Server указан каталог, в котором хранятся конфигурационные файлов ВМ (в нашем примере D:\VMStore).

Откройте этот каталог в File Explorer и найдите каталог с именем зависшей виртуальной машины. Скопируйте GUID, который указан в имени конфигурационного файла ВМ с расширением *.vmcx.

Теперь нужно запустить диспетчер задач (Task Manager) и перейти на вкладку Details. Все виртуальные машины запускаются в рамках собственного экземпляра процесса vmwp.exe. Чтобы определить какой процесс за какую ВМ отвечает, нам нужен полученный ранее GUID зависшей ВМ. Найдите процесс vmwp.exe, у которого в столбце User name содржится GUID вашей ВМ. Завершите данный процесс (End Task).

По аналогии вы можете найти и завершить процесс подвисшей виртуальной машины на хосте Hyper-V с помощью утилиты Process Explorer.

1. Запустите Process Explorer с правами администратора и нажмите Find Handle or DLL (или нажмите Ctrl-F );
2. В строке поиска укажите путь к виртуальному диску зависшей виртуальной машину (*.vhdx);
3. Process Explorer выведет все процессы, которые используются VHDX файл виртуальной машины;
4. Найдите процесс виртуальной машину vmwp.exe и завершите его.

Виртуальная машина будет принудительно остановлена. Теперь вы сможете делать с ней все что угодно.

Выключить зависшую ВМ на Hyper-V с помощью PowerShell

Гораздо проще найти и завершить процесс зависшей виртуальной машины с помощью PowerShell. Запустите консоль PowerShell с правами администратора (учетная запись должна состоять в локальной группе Hyper-V administrators).

В этом случае встроенный командлет Stop-VM из модуля Hyper-V PowerShell не позволит вам выключить ВМ. Если попробовать выполнить команду Stop-VM –Force , она также зависает. Очевидно ожидает ответа от ВМ.

Вы также можете завершить процесс ВМ по ее VM ID. Можно получить GUID ВМ по ее имени. Например, для ВМ с именем SVM-GUARDEDHOST1, выполните команду:

$VMGUID = (Get-VM «SVM-GUARDEDHOST1»).ID

Если вы не хотите набирать полное имя ВМ, можете вывести список всех ВМ, зарегистрированных на данном хосте Hyper-V и их ID:

Get-VM | Select VMName, VMId, Parh

Скопируйте VMID нужной вам ВМ из полученного списка.

Теперь нужно найти идентификатор процесса (PID) ‘vmwp.exe’ для вашего VMGUID:

Затем нужно принудительно завершить рабочий процесс подвисшей виртуальной машины Hyper-V с помощью команды Stop-Process:

Stop-Process ($VMWMProc.ProcessId) –Force

Совет. У нас также описана аналогичная процедура по завершению процесса зависшей ВМ на хосте VMWare ESXi.

Виртуальная машина Hyper-V зависает при резервном копировании

При выполнении резервного копирования ВМ на хосте Hyper-V вы можете столкнуться с зависанием виртуальной машины Hyper-V в состоянии Running и статусом Backing up. При этом вы не можете остановить или запустить ВМ через Hyper-V Manager.

Если вы не хотите перезагружать хост Hyper-V, проверьте сначала состояние службу «Microsoft Hyper-V VSS Writer»:

vssadmin list writers

Убедитесь, что команда не вернула ошибку. Значит нужно перезапустить службу «Hyper-V Virtual Machine Management» с помощью команды PowerShell:

Get-service vmms | stop-process
Убедитесь, что процесс vmms.exe завершен. Если нет, завершите его принудительно:

Get-Process | Where-Object < $_.ProcessName -eq 'vmms' >| Stop-Process

Теперь можно запустить службу Hyper-V:

Start-Service vmms
Перезапуск службы Virtual Machine Management должно сбросить состояние VSS Writer для Hyper-V.

Hyper-V: Не удалось изменить состояние виртуальной машины

Иногда бывает, что даже после завершения зависшего процесса вы не можете включить ВМ и она зависает в статусе Starting с ошибкой:

Virtual Machine Connection Не удалось изменить состояние. Failed to Change State.

В этом случае проверьте следующие варианты:

• Проверьте что на диске, на котором хранятся файлы ВМ достаточно свободного места;
• Если в настройках ВМ подключен ISO образ, проверьте этот файл доступен;
• Проверьте сетевые настройки ВМ. Виртуальные сетевые адаптеры должны быть подключены к существующему виртуальному коммутатору Hyper-V (не должно быть статуса Network Adapter – Configuration Error);
• Проверьте, что служба Hyper-V Virtual Management Service (VMMS) запушена, и не зависла в статусе Stopping;
• Убедитесь, что ваш антивирус не блокирует доступ к файлам ВМ. Добавьте пути к каталогу с виртуальными машинами в исключения антивируса ( см. как добавить исключения во встроенный антивирус Windows Defender в Windows Server);
• Проверьте ошибки в журнале событий Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Hyper-V-Worker;
• Отключите режим сна и гибернации в гостевых операционных системах виртуальных машин. В Windows спящий режим отключается через Control Panel –>Power Options -> Change plan settings -> Put the computer to sleep -> Never. Чтобы отключить спящий режим в гостевой ОС с Ubuntu Linux, выполните команду: systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Если методы, описанные выше, не помогли, похоже, что вам придется перезагрузить весь хост Hyper-V.

Предыдущая статья Следующая статья

Объединение Snapshot в Hyper-V

Правильное объединение снимков осуществляется через их удаление в консоли управления Hyper-V от самого старого к самому новому и перезагрузкой виртуальной машины. Если по каким-то причинам сделать это не возможно, то потребуется объединять снимки вручную.

1. Изменяем расширение снимков виртуальной машины с *.avhd на *.vhd;
2. Щёлкаем правой кнопкой мыши по гипервизору в диспетчере и открываем оснастку «Изменить диск» / «Edit Disk»;
3. Далее кнопкой «Обзор» выбираем снимок сделанный позже всего (самый свежий снимок);
4. Указываем «Объединить» / «Merge»; Щёлкаем по «К родительскому виртуальному диску»;
5. Потом открывается информационное окно, в котором будет виден родитель объединяемого файла.
6. Нажимаем «Готово» и процесс слияния будет запущен.

Если снимков несколько — повторите теже самые действия.

SKY — IT-решения для бизнеса, 2012–2023 г.

Избегайте ошибок при развертывании Hyper-V R2

Компания Microsoft проделала большую работу, направленную на облегчение использования Hyper-V. Уже нет необходимости обладать какими-то специальными навыками для того чтобы создать виртуальную машину и запустить ее в работу. В процессе установки и настройки Hyper-V, используется множество мастеров, помогающих создать виртуальную среду в соответствии с лучшими практиками. Однако, несмотря на все улучшения, существует еще много мест, которые могут вызвать ошибки, из-за чего ИТ специалисты подвергают большому риску свои виртуальные среды и даже не подозревают об этом.

Ниже описаны наиболее распространенные ошибки при развертывании Microsoft Hyper-V и способы, позволяющие их избежать.

Игнорирование сети управления

При развертывании роли Microsoft Hyper-V необходимо выделить отдельную сетевую карту для управления. Однако, многие не желают терять сетевой интерфейс, используя его только для управления. Многие специалисты считают, зачем выделять отдельный сетевой интерфейс на управление когда и так все работает. Зачем же нужен отдельный порт управления?

На хосте Hyper-V может выполняться несколько виртуальных машин. В случае, если через сетевой интерфейс управления работают виртуальные машины, существует возможность получить доступ к виртуальным машинам, их жестким дискам и данным. Поэтому хост Hyper-V должен управляться через отдельный сетевой интерфейс в специально выделенной для администрирования сети. Без соблюдения этого правила, вы подвергаетесь значительным рискам.

Использование неверного вида диска

При создании виртуальной машины, создается виртуальный жесткий диск. Это динамически расширяющийся диск, представляющий собой файл в системе хранения хоста. При установке задается объем жесткого диска виртуальной машины, первоначально этот объем не занимает все место на жестком диске хоста, происходит постепенный рост виртуального жесткого диска по мере необходимости. Пример, если при создании новой виртуальной машины вы указали размер жесткого диска 150 Гб, установили ОС объемом 7 Гб, файл жесткого диска виртуальной машины будет размером 7 Гб.

Такое динамическое изменение размеров жесткого диска обладает не только плюсами, но вызывает проблемы производительности. Поскольку при добавлении необходимого места расходуется мощность хоста, особенно это заметно при добавлении в виртуальную машину файлов большого размера.

Еще одной проблемой, вызванной динамическими дисками, может служить сложность отслеживания необходимого объема на жестком диске хоста. Возможны ситуации, когда динамический диск должен расти, а свободного места на жестком диске хоста нет.

Избежать подобные ситуации позволяют диски фиксированного объема (fixed disks).С fixed disks при создании виртуальной машины, сразу создается файл VHD необходимого объема. Кроме этого, диски с фиксированным объемом не создают проблем производительности.

Некорректное использование Snapshot

Одной из главных причин, из-за которой системные администраторы используют Microsoft Hyper-V, является возможность создания снимков системы (Snapshot). Это простой способ возвратиться в исходное состояние в случае возникновения непредвиденных обстоятельств. Однако, существует несколько проблем, связанных с использованием снимков.

Первое, и самое важное, следует помнить, что создание Snapshot не заменяет необходимость делать резервные копии систем. Создание снимков не позволяет выполнить пофайловое восстановление в случае необходимости, и не решит возможных проблем в случае сбоя сервера Hyper-V.

Второе, необходимость перерыва в работе виртуальных машин. По умолчанию Snapshot файлы сохраняются там же, где находится VHD файл, поэтому они могут служить причиной нехватки места для VHD файлов. В случае нехватки места, первым порывом, для обеспечения необходимого места, может стать удаление Snapshot файлов, используя Hyper-V Manager. Файлы будут помечены для слияния с родительским образом, а само слияние произойдет только после завершения работы виртуальной машины. В случае большого количества снимков, слияние может занять продолжительное время.

Большое количество CPU

Использование многоядерных процессоров стало обыденным явлением, средний современный типичный сервер содержит 8 ядер и это становится нормой. Не без основания считается, что большое количество ядер повышает производительность. Microsoft Hyper-V позволяет использовать до четырех (в случае версии Hyper-V R2 до 32 процессоров) на виртуальную машину.

При использовании виртуальных серверов необходимо соблюдать пропорцию 2 виртуальных процессора на одно физическое ядро. В случае четырех ядерных процессоров это означает, что вы не должны использовать больше восьми виртуальных процессоров для увеличения производительности. Кроме того, виртуальная машина не может использовать отдельное ядро, в случае выделения ей четырех ядерного процессора. Вы должны иметь серьезную причину, что бы использовать в вашей виртуальной машине многопроцессорную конфигурация, такой причиной может служить использование большой базы данных.

Неполное использование возможностей виртуальной сети

Виртуальные свитчи расширяют вашу сетевую топологию. Сетевые администраторы настраивают виртуальные сети, или VLAN, используют 802.1Q транкинги, что бы сделать сеть более эффективной и легкой в управлении.

При подключении к порту свитча, мы все еще считаем, что наш хост является конечной точкой этого сетевого подключения, однако это уже не так. При использовании VLAN, существует возможность расширить функциональность до ваших виртуальных машин. Используя VLAN и транкинг, у вас отпадает необходимость в конфигурировании отдельной сетевой карты для каждой подсети. Вы можете подключать виртуальные машины к различным сетям, используя меньшее количество сетевых портов. Это особенно ценно в случае, когда вы ограниченны количеством сетевых портов, например при использовании blade серверов.

Microsoft Hyper-V позволяет администраторам использовать виртуализацию без необходимости дополнительного специального обучения. Однако, легкость установки Hyper-V сервера еще не говорит о том, что нет особых моментов, которые необходимо учитывать. Использование виртуализации дает множество положительных результатов, которые позволяют забыть все недостатки, но, только до того момента, когда произойдет сбой. Чтобы избежать этого сценария, принимайте правильные решения на начальном этапе создания виртуальной среды.

Резервное копирование виртуальных машин Hyper-V: текущие тенденции и решения

01.12.2023

itpro

Hyper-V, Windows Server 2019, Резервное копирование

комментариев 19

Эта статья посвящена особенностям организации резервного копирования виртуальных машин, запущенных в среде Microsoft Hyper-V. Мы рассмотрим требования к средствам резервного копирования Hyper-V, стратегии резервного копирования и основные бесплатные и коммерческие продукты в этой нише.

Несмотря на то, что в среде Hyper-V доступно большое количество технологий обеспечения высокой доступности и отказоустойчивости ВМ (кластера, Live Migration, репликация, и т.д.), системному администратору необходимо не забывать о классическом резервном копировании виртуальных машин.

Как работает резервное копирование виртуальных машин Hyper-V?

Рассмотрим упрощенно схему работы любого современного средства для бэкапа виртуальных машин Hyper-V.

Есть два подхода к резервному копированию ВМ:

• Резервное копирование ВМ с хоста Hyper-V (host-level VM backup) – администратор управляет инструментом резевного копирования на уровне всего хоста Hyper-V;
• Резервное копирование с помощью агента, установленного в гостевой ОС (guest-level VM backup) – используются довольно редко. В основном для приложений, которые не позволяют корректно создать бэкап через VSS.

В основе всех современных средств резервного копирования ВМ Hyper-V лежит технология снапшотов (снимков). Снимок содержит состояние ВМ на определенный момент времени и содержит как содержимое виртуальных жестких дисков, так содержимое памяти и настройки виртуальной машины.

Вот как упрощенно выглядит типовой процесс резервного копирования в Hyper-V:

1. Средство резервного копирования (СРК) отдает команду хосту Hyper-V на создание снимка ВМ;
2. Гипервизор создает новые файлы (дельта-файлы) и ВМ продолжает свою работу, сохраняя изменения в этих файлах;

В качестве альтернативы полноценному резервному копированию, можно использовать встроенную возможность Hyper-V по экспорту запущенных ВМ. Hyper-V позволяет экспортировать все файлы запущенной ВМ в отдельный каталог:

Export-VM -Name win10 -Path ‘\\fs01\backup\win10’ -CaptureLiveState CaptureSavedState

Основные требования к средствам резервного копирования ВМ Hyper-V

Это в общих чертах о резервном копировании Hyper-V, но на деле возникает куча нюансов и проблем. Попробую перечислить наиболее распространены проблемы:

1. Чем дольше средство резервного копирования забирает снапшот (бэкап) к себе, тем больше изменений накапливается в дельта файлах. При большом количестве изменений внутри ВМ за время копирования файлов, процесс слияния файлов при удалении снапшота может вызывать высокую нагрузку на диски, Hyper-V хост и саму ВМ. В Hyper-V Server 2016 для ускорения процесса резервного копирования используется технологий ResilientChangedTracking, которая позволяет средству резервного копирования копировать только блоки данных, измененные с момент последнего бэкапа. При этом не нужно «забирать» ВМ целиком.
2. При копировании данных снимка ВМ по LAN сети с хоста Hyper-V на хранилище резервных копий возможно вызвать высокую нагрузку на сеть. Рекомендуется использовать отдельный интерфейс сервера для трафика резервного копирования, или копировать данные через SAN сеть.
3. Если вы используете систем хранения (СХД) для хранения файлов ВМ, вы можете воспользоваться возможностями СХД по интеграции со средствами резервного копирования (аппаратные снапшоты).
4. Изначально гостевая ОС не знает о том, что создается ее резервная копия. Соответственно при попытке восстановить ВМ из такого бэкапа, ОС пытается продолжить свою работу с момента создания снимка. В некоторых случаях это может вызвать проблемы как с самой ОС, так и с потерей данных в запущенными внутри нее приложениях (особенно в транзакционных, таких как Exchange, SQL, ADDS и т.п.). Для преодоления этой проблемы в Hyper-V 2016 появился новый тип снимков — Production Checkpoints (Microsoft рекомендуется применять обычные снимки — Standard Checkpoint только в тестовых и лабораторных средах, или для бэкапа остановленных виртуальных машин);Для работы Production Checkpoints в гостевой ОС средств должны быть установлены компоненты интеграции Hyper-V, и включена служба Volume Shadow Copy (Windows) или заморозки файловой системы fsfreeze (Linux). Однако состоянии памяти при этом не копируется. Т.е. Hyper-V уведомляет гостевую ОС о создании снимка, приложение с поддержкой VSS корректно завершает текущие транзакции, переходит в консистентное состояние и создает снимок ВМ. При восстановлении из такого снимка гостевая ОС выключена (т.к. состояние памяти не сохранялось), после включения она считает, что просто произошло аварийное отключение по питанию. Приложение (если оно поддерживает VSS) при этом начинает работу с сохранённого согласованного состояния.
5. Для экономии места на устройстве хранении резервной копий рекомендуется использовать дедупликацию. Если вы используете дифференциальные диски, нужно чтобы средство резервного копирования поддерживало эту технологию. Иначе вы можете хранить одинаковые данные ВМ несколько раз.
6. При большой плотности виртуальных машин на хосте желательно иметь возможность планирования времени резервного копирования ВМ, чтобы избежать чрезвычайно нагрузки на продуктивные системы в производственное время.
7. Если вам нужно хранить несколько копий виртуальной машины, нужно обеспечить управление количеством хранимых копий ВМ.
8. Настройте мониторинг СРК и устройства хранения резервных копий. Не хочется в определенных момент узнать, то резервное копирование не работает, т.к. на СХД под бэкапы закончилось место. Здесь же нужно вспомнить про средство верификации резервных копий.
9. Некоторые СРК поддерживают гранулярное восстановление отдельных файлов/папок без необходимости развёртывания целиком ВМ или ее виртуального диска.

Примечание. Многие СРК позволяют, например, восстановления конкретные хранилища, ящики и даже отдельных писем из резервной копии ВМ с Exchange Server.

Реализуйте классическую стратегию резервного копирования 3-2-1 (три копии, на двух разных носителях, один из которых на другой площадке).

Далее мы рассмотрим несколько популярных решений по организации резервного копирования ВМ на Hyper-V с точки зрения рассмотренных возможностей.

Резервное копирование Hyper-V с помощью встроенного Windows Server Backup

Вы можете бесплатно реализовать резервное копирование виртуальных машин Hyper-V с помощью встроенного Windows Server Backup (WSB). WSB позволяет настроить резервное копирование ВМ из графического интерфейса или с помощью утилиты командной строки wbadmin.

Windows Server Backup доступен как в полноценных версиях Windows Server Standard/Enterpriser так и в бесплатном Hyper-V Server.

Вы можете установить Windows Server Backup из консоли Server Manager или с помощью команды:

Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools

Чтобы настроить задание резервного копирования ВМ из графического интерфейса, запустите оснастку wbadmin.msc .

1. Разверните раздел LocalBackup и выберите Backup Schedule;
2. Выберите тип резервного копирования Custom -> и нажмите Add Items;
3. Разверните Hyper-V и выберите виртуальные машины, которые вы хотите бэкапить;
4. Далее вы можете настроить расписание резервного копирования ВМ;
5. Выбрать хотите ли вы сохранять резервную копию на отдельный диск или в сетевую папку (UNC путь);
6. Если вы не используете других средств резевного копирования нажмите кнпоку Advanced Settings и включите опцию VSS full Backup.

Основной недостаток графического интерфейса Windows Server Backup – вы можете создать только одно задание резервного копирования, которое будет перезатирать предыдущие копии.

Поэтому администраторы Hyper-V для настройки резервного копирования виртуальных машин предпочитают использовать утилиту командной строки wbadmin.

Чтобы создать резервную копию ВМ с именем «Server 1» на локальный диск D:\ , выполните команду:

wbadmin start backup –backupTarget:D: –hyperv:»Server 1″

Не рекомендуется хранить резервную копию ВМ на этом самом сервере Hyper-V. Желательно использовать удаленное хранилище.

WSB создаст снапшот для ВМ, и скопирует виртуальные диски и состояние ВМ в каталог D:\WindowsImageBackup\имявашегохостаHyper .

Вы можете выполнить резервное копирование сразу нескольких ВМ. В этом примере вы сохраним их в сетевую папку:

wbadmin start backup -backuptarget:\\192.168.1.100\VMbackup: -hyperv:»TestVM01,TestVM02″ -allowDeleteOldBackups -quiet

При хранении резервных копий ВМ в сетевой папке, Служба VSS не позволяет хранить несколько версий ВМ в сетевой папке. При использовании этого способа старая резервная копия всегда будет перезатираться.

При резервном копировании виртуальных машин с VSS-aware application (такими как контроллер домена AD, Exchange Server или MSSQL) можно сообщить приложению в ВМ о том, что нужно обновить данные в журнале архивации.

wbadmin start backup -backuptarget:\\192.168.1.100\VMbackup: -hyperv:MSK-DC1 -vssFull

В гостевой ОС должны быть установлены компоненты интеграции Hyper-V.

Вы можете создать в планировщике Windows задание с командной wbadmin для автоматического резервного копирования виртуальных машин по настроенному. Чтобы резервная копия создавалась без запроса пользователю, добавьте в команду wbadmin параметр -quiet .

Чтобы получить список зарегистрированных в WSB резервных копий, выполните команду:

wbadmin get versions

Удалить самую старую резевную копию:

wbadmin delete backup -backupTarget:c: -deleteOldest

Либо вы можете удалить одну из старых резервных копий ВМ по имени версии (Version identifier):

wbadmin delete backup -backupTarget:c: -version:11/08/2023-10:13

Чтобы восстановить ВМ из резервной копии Windows Server Backup, нужно получить ее идентификатор в архиве. Вывести список элементов в резервной копии.

wbadmin get items -version:11/08/2023-09:33

Скопируйте VM identifier и подставьте его в следующую команду:

wbadmin start recovery -itemtype:hyperv -version:11/08/2023-09:33 -items:7B415605-0C7B-4349-AB80-9156BCB79E44

С помощью опций AlternateLocation и RecoveryTarget:path вы можете восстановить ВМ в альтернативный каталог.

Windows Server Backup позволяет восстановить только ВМ целиком. Нельзя восстановить отдельный диск, файл или папку. Однако вы можете вручную смонтировать к вашей ВМ VHDX диск с резервной копией и самостоятельно скопировать файл, которые нужно восстановить.

При всей своей простоте WSB достаточно надежное решение для резервного копирования Hyper-V, работает довольно быстро и позволяет управлять расписанием резервного копирования. Недостатки Windows Server Backup:

• Нет средств мониторинга выполнения бэкапов, проверки целостности резервных копий ВМ;
• Сложно управлять резервным копированием в средних и крупных инсталляциях Hyper-V (подходит для небольших сред с 1-2 хостами Hyper-V);
• Нельзя автоматически восстановить конкретный файл или состояние приложения;
• При большой плотности и размерах виртуальных машин на хосте вам придется с помощью планировщика Windows настраивать порядок создания резервных копий, чтобы не вызвать перегрузки сервера, а также высокой нагрузки на сети LAN/SAN/ iSCSI в рабочие часы (если вы храните бэкапы на другом хранилище).

Сторонние средства резервного копирования Hyper-V

МАТЕРИАЛ ПОДГОТОВЛЕН ПРИ СОДЕЙСТВИИ BACKUPSOLUTION.RU
Специализированный поставщик решений для резервного копирования и восстановления данных

При большом количестве хостов Hyper-V и виртуальных машин, использовать встроенный Windows Server Backup очень сложно. Вам в любом случае придется выбирать одно из сторонних коммерческих решений. Однозначно говорить, что тот или иной продукт будет идеальным решением для резервного копирования Hyper-V нельзя, слишком много нюансов нужно учесть. Это и количество хостов, лицензионные ограничения, необходимый функционал, архитектура сети и т.д.

На рынке представлено большое количество коммерческих и бесплатных продуктов для резервного копирования, и запутаться в них очень сложно. Обычно для оценки лидеров ниши используется магический квадрант Gartner. Я нашел такую картинку, характеризующие основных игроков и лидеров на рынке резервного копирования для дата-центров.

Как вы видите, Гартнер среди лидеров решений по резервному копированию выделяет компании и продукты:

• Commvault
• Dell Technologies
• Cohesity
• Veeam (в бесплатной редакции Veeam Backup Free Edition позволяет бэкапить до 10 ВМ)
• Rubrik
• Veeam
• Veritas Technologies (Symantec — Veritas Backup Exec)
• Microfocus (HPE Data Protector)

В рамках одной статьи оценить и сравнить все продукты довольно сложно, поэтому попробуем рассмотреть возможности нескольких программ – лидеров рынка по резервному копированию Hyper-V.

• Veritas Backup Exec
• Commvault Backup
• Veeam Backup
• Acronis Backup

Я составил небольшую сравнительную таблицу с интересными мне возможностями этих средств резервного копирования (рассматривается функционал версий, актуальных на момент написания статьи).

Функционал/ Продукт	Veritas Backup Exec 20.2	Commvault Backup and Recovery 11	Veeam Backup & Replication 9.5	Acronis Backup 12.5
Резервное копирование файловых систем	Windows / Linux	Windows / Linux / IBM AIX / HP-UX	Windows / Linux / IBM AIX / HP-UX. Агенты для физических систем автономны, не поддерживают совместное использование хранилищ групповые политики	Windows / Linux
Передача резервных копий дисковых массивов по NDMP	+ Поддержка NDMP v4+. Список поддерживаемых хранилищ есть на сайте veritas. Не поддерживается инкрементальное и дифференциально копирование, бэкап только LUN целиком и нельзя восстановить отдельные файлы.	+ Поддержка прямого резервного копирования данных с файловых устройств NAS. На сайте Commvault есть список поддерживаемых версий файловых систем разных производителей. При использовании этого типа резервного копирования данные отправляются напрямую с NAS через MediaAgent (прокси сервер) на устройство хранения, минуя управляющий сервер CommServe. Поддержка бэкапов отдельных vmdk файлов.	+ Поддержка NDMP (v4 и выше) появилась относительно недавно. Поддерживается бэкап только LUN целиком. Поддерживается до 10 точек восстановления (на NetApp до 30).	—
Передача моментальных снимков ВМ по SAN	+ На сайте Veritas в секции Hardware Compatibility List представлен список совместимых HBA адаптеров, SAN свичей	+ Поддерживается бэкап по SAN как для ESXi так и для Hyper-V хостов	+ Необходимо дополнительная физическая машина с ролью выделенного прокси сервера Veeam, подключенного к той же сети SAN и презентованными LUN	Поддержка моментальных снимков только в VMware vSphere для хранилищ NetApp с Data ONTAP
Репликация резервных копий в несколько хранилищ (в том числе на удаленную площадку)	+	+	+	+
Поддержка гранулярного восстановления приложений и БД	Microsoft SQL / Exchange / AD	Microsoft SQL / Exchange / AD / Domino / DB2 / MySQL / Oracle	Microsoft SQL / Exchange / AD / Oracle (только для виртуализированных приложений, не поддерживается на физических системах)	Microsoft SQL / Exchange / AD
Управление аппаратными снимками СХД	+	+ (IntelliSnap)	+ (список поддерживаемых вендоров и моделей СХД ест ь на сайте, для некоторых необходима установка отдельного модуля интеграции)	+
Лицензирование для сред виртуализации	Хост / сокет / Объем данных	Сокет / Объем данных	На сокет (процессор)	На хост
Стоимость 1 лицензии (ориентировано)	От 85 тыс. р.	190 тыс. р.	70 тыс. р. (редакция Standard), 200 тыс. р. (редакция Enterprise Plus)	45 тыс. р. (редакция Standard), 95 тыс. р. (редакция Advanced)

Перед принятием решений о выборе того или иного решения стоит составить список требований к продукту резервного копирования Hyper-V, список имеющегося оборудования и необходимый функционал. У большинства известных продуктов резервного копирования есть бесплатные версии с некоторыми ограничениями, обычно их достаточно для оценки функционала.

Предыдущая статья Следующая статья