Restoring the Virtual Machines
Restoring the VMs is done entirely by the host operating system; the VSS writers in the child VMs are not involved.
The following procedure describes how to restore VMs.
To restore virtual machines
- During the processing of the PreRestore event, the Hyper-V VSS writer turns off and deletes any VMs that are about to be restored.
- After all VSS writers have processed the PreRestore event, the files are restored.
- During the processing of the PostRestore event, the Hyper-V VSS writer calls the IVssComponent::GetFileRestoreStatus method. If the return is not VSS_RS_ALL, then the Hyper-V VSS writer calls the SetWriterFailure method and returns FALSE from the OnPostRestore method.
- For each VM that was restored, the Hyper-V VSS writer registers the VM with the Hyper-V management service. If the VM is restored to a nondefault location, a symbolic link is created in the default location linking to that location.
- For each VHD that was restored, the location is compared with the one specified for that VM. If the location is different, then the configuration is updated with the proper location.
- The network configuration is updated. If the virtual switches that the VM was connected to when it was backed up still exit, new ports are created and connected to the VM.
Backing Up the Virtual Machines
Hyper-V uses one of two mechanisms to back up each VM. The default backup mechanism is called the «Saved State» method, where the VM is put into a saved state during the processing of the PrepareForSnapshot event, snapshots are taken of the appropriate volumes, and the VM is returned to the previous state during the processing of the PostSnapshot event.
The other backup mechanism is called the «Child VM Snapshot» method, which uses VSS inside the child VM to participate in the backup. For the «Child VM Snapshot» method to be supported, all of the following conditions must be met:
-
Backup (volume snapshot) Integration Service is installed and running in the child VM. The service name is «Hyper-V Volume Shadow Copy Requestor».
Windows 2000: Backup Integration Service is not supported.
-
The child VM must be in the running state.
-
The Snapshot File Location for the VM is set to be the same volume in the host operating system as the VHD files for the VM.
-
All volumes in the child VM are basic disks and there are no dynamic disks.
-
All disks in the child VM must use a file system that supports snapshots (for example, NTFS).
In general, the process for backing up VMs is the same as described in Overview of Processing a Backup Under VSS. The unique behavior happens when the Hyper-V VSS writer (part of the «Hyper-V Virtual Machine Management» service) processes the PrepareForSnapshot event. If the backup was done using the «Child VM Snapshot» method, there is additional processing done but it is not visible to the child VM.
The following procedure describes how to back up VMs.
To back up virtual machines
- For each VM in the writer metadata, if the «Saved State» method is used, the VM is put into a saved state. For VMs using the «Child VM Snapshot» method, the Hyper-V Volume Shadow Copy Requestor Service in the child VM processes the backup as detailed in Overview of Processing a Backup Under VSS. All VSS events in the child VM occur during the host operating system processing of the PrepareForSnapshot event.
- After all VMs have either been put in the saved state or had snapshots taken, the Hyper-V VSS writer returns from the PrepareForSnapshot event. No processing is done by the Hyper-V VSS writer during the Freeze and Thaw events.
- When the Hyper-V VSS writer processes the PostSnapshot event, VMs that were backed up using the «Saved State» method and were put into a saved state by the Hyper-V VSS writer are returned to the state they were in before the backup started. For the VMs that were backed up using the «Child VM Snapshot» method, the host image of the VHD files that had the snapshots taken are rolled back to the snapshot taken during the processing of the PrepareForSnapshot event. This processing is done independently of the VSS writers in the child VMs so the snapshots taken must be auto-recoverable. (VSS_VOLSNAP_ATTR_NO_AUTORECOVERY is not set in the context.)
Partial backups are not supported. If any VM fails to create a snapshot, no VMs will be backed up.
Note
Pass-through and iSCSI disks are not visible to the host operating system and therefore not backed up by the Hyper-V VSS writer. Backups of these volumes must be done entirely within the VM.
Какой диск выбрать в kvm — lvm, raw (img) или qcow2
В kvm есть несколько типов дисков, которые вы можете использовать в своей работе. Они имеют принципиальные отличия как по своей работе, так и по способам бэкапа. Выбирать тот или иной тип нужно в зависимости от ваших задач. Рассмотрим эти типы подробнее.
LVM. Тут все понятно. Использование lvm томов в виде дисков виртуальных машин. Такой диск будет блочным устройством и должен работать быстрее всех остальных типов, так как нет лишней прослойки в виде файловой системы.
Плюсы:
- Снэпшоты средствами самого lvm, с них легко снять бэкап без остановки виртуальной машины.
- Максимальное быстродействие.
- Легко изменить размер диска.
Минусы:
- Более сложное управление по сравнению с дисками в виде отдельных файлов.
- Менее гибкое управление пространством диска. Если весь диск разбить на lvm разделы для виртуалок, то места на нем не останется, даже если вируталки будут пустые.
- Более сложный перенос на другой сервер.
RAW. Это обычный формат сырых данных. Среди дисков в виде файлов это будет самый простой и быстрый вариант. Все данные пишутся как есть без дополнительных обработок и служебной информации. Формат является универсальным для большинства популярных гипервизоров.
Плюсы:
- Максимальная простота и производительность среди образов в виде файла.
- Универсальный формат с поддержкой в большинстве гипервизоров.
- Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
Минусы:
- Не поддерживает снепшоты ни в каком виде.
- Занимает сразу все выделенное пространство на диске, даже если внутри виртуальной машины место будет свободно. Из-за отсутствия фрагментации в некоторых случаях это может оказаться плюсом.
QCOW2. Родной формат для гипервизора QEMU. Расшифровывается как QEMU Copy-on-write. Этот формат позволяет создавать динамические диски для виртуальных машин, а так же поддерживает снепшоты. Теоретически, скорость работы должна хоть и не сильно, но уступать RAW. Как обстоит дело на практике, я не знаю, не замерял и подробно эту информацию не проверял.
Плюсы:
- Поддержка снепшотов и динамических дисков. Как следствие — более удобное управление дисковым пространством.
- Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.
Минусы:
Более низкая производительность, по сравнению с другими типами образов.
У каждого типа есть свои преимущества и недостатки. Lvm проще всего бэкапить, но им сложнее всего управлять. Для того, кто хорошо знаком с lvm это не проблема, если сталкиваешься первый раз, то возникает много вопросов. У raw нет снепшотов, лично для меня это большой минус, я этот формат вообще не рассматриваю. Если нет максимальной нагрузки на дисковую подсистему, то QCOW2 мне кажется наиболее приемлемым вариантом. Собственно, ниже и пойдет рассказ, как совместить удобство управления QCOW2 и простоту бэкапов и снэпшотов lvm. Я покажу, как сделать живой бэкап виртуальной машины kvm в формате qcow2 без остановки виртуальной машины.
Бэкап изнутри виртуальных машин
1.1. Бэкап сегодняшнего дня
Причем, для серверных и настольных (клиентских) Windows бэкапы формируются разные. И разница заключается в том, что для серверных ОС у нас получатся снимки каждого бэкапа, а вот для настольных — снимок останется всегда только последний. Спросите, а что это за такой инкрементальный бэкап? А «инкрементальный» он остается, потому чтоТо есть для серверной Windows снимки остаются тоже только последние.Позже, выявил, что нет никакой разницы в работе wbadmin на серверной и клиентской ОС. Разве, что разница есть в интерфейсе. wbadmin производит инкрементальный бэкап (кроме первого бэкапа), если указан жесткий диск в ключе -backupTarget (команда использует ключ по умолчанию -vssСopy). Или производит полный бэкап, если добавить ключ -vssFull.
Дополнительные сведения о Hyper-V резервного копирования виртуальных машин
Резервное копирование виртуальных машин с помощью Windows резервного копирования сервера
-
При выполнении резервного копирования виртуальных машин необходимо резервное копирование всех томов, в которых содержатся файлы для виртуальной машины, включая файл InitialStore.xml (в C:\ProgramData\Microsoft\Windows\Hyper-V, по умолчанию) и том(ы), содержащий файлы VHD(s) и XML конфигурации. Например, если файлы конфигурации виртуальной машины хранятся в D: томе, а файлы виртуального жесткого диска (VHD) хранятся в файле E: том, а InitialStore.xml файл хранится в C: volume, необходимо архивация C:, D: и E: томов.
-
Виртуальные машины, на которые не установлены службы интеграции, будут помещаться в сохраненное состояние во время создания снимка VSS.
-
Виртуальные машины, работающие с операционными системами, которые не поддерживают VSS, такие как Microsoft Windows 2000 или Windows XP, будут поставлены в сохраненном состоянии во время создания снимка VSS.
-
Виртуальные машины, содержащие динамические диски (не динамически расширяющиеся) должны быть отламывными в автономном режиме.
Примечание
Windows Резервное копирование сервера не поддерживает резервное копирование виртуальных Hyper-V в кластерных общих томах (томах CSV).
Восстановление виртуальных машин с помощью Windows резервного копирования сервера
Чтобы восстановить виртуальные машины, выполните следующие действия:
- Начните Windows резервного копирования сервера в административных средствах.
- В меню Действия нажмите кнопку Восстановление.
- Выберите сервер, на который необходимо восстановить данные, а затем нажмите кнопку Далее.
- Выберите дату и время восстановления, а затем нажмите кнопку Далее.
- Выберите тип восстановления Приложений и нажмите кнопку Далее.
- Выберите Hyper-V, а затем нажмите кнопку Далее.
- Выберите расположение восстановления и нажмите кнопку Далее.
-
Щелкните Восстановление, чтобы запустить процесс восстановления.
Примечание
Все тома, в которые будут вмещаяся файлы для виртуальной машины, будут восстановлены. Отдельные виртуальные машины не могут быть восстановлены с помощью Windows резервного копирования сервера.
Виртуальные машины, содержащие два или более снимков, не будут восстановлены. Чтобы решить эту проблему, выполните следующие действия:
-
Начните Hyper-V в области административных инструментов.
-
Удалите виртуальную машину, которая не была восстановлена.
-
Начните Windows резервного копирования сервера в административных средствах.
-
В меню Действия нажмите кнопку Восстановление.
-
Выберите сервер, на который необходимо восстановить данные, а затем нажмите кнопку Далее.
-
Выберите дату и время восстановления, а затем нажмите кнопку Далее.
-
Выберите тип восстановления файлов и папок и нажмите кнопку Далее.
-
Выберите каталог, в котором хранятся снимки, а затем нажмите кнопку Далее.
Примечание
По умолчанию снимки находятся в следующем каталоге:C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots
-
Выберите расположение, в котором должны быть восстановлены снимки, а затем нажмите кнопку Далее.
-
Щелкните Восстановление, чтобы запустить процесс восстановления.
-
После завершения восстановления выполните еще одно восстановление. Однако используйте тип восстановления Приложений и выберите Hyper-V для правильного восстановления виртуальных машин.
Back up replica virtual machines
If MABS is running on Windows Server 2012 R2 or greater, then you can back up replica virtual machines. This is useful for several reasons:
Reduces the impact of backups on the running workload — Taking a backup of a virtual machine incurs some overhead as a snapshot is created. By offloading the backup process to a secondary remote site, the running workload is no longer affected by the backup operation. This is applicable only to deployments where the backup copy is stored on a remote site. For example, you might take daily backups and store data locally to ensure quick restore times, but take monthly or quarterly backups from replica virtual machines stored remotely for long-term retention.
Saves bandwidth — In a typical remote branch office/headquarters deployment you need an appropriate amount of provisioned bandwidth to transfer backup data between sites. If you create a replication and failover strategy, in addition to your data backup strategy, you can reduce the amount of redundant data sent over the network. By backing up the replica virtual machine data rather than the primary, you save the overhead of sending the backed-up data over the network.
Enables hoster backup — You can use a hosted datacenter as a replica site, with no need for a secondary datacenter. In this case, the hoster SLA requires consistent backup of replica virtual machines.
A replica virtual machine is turned off until a failover is initiated, and VSS can’t guarantee an application-consistent backup for a replica virtual machine. So the backup of a replica virtual machine will be crash-consistent only. If crash-consistency can’t be guaranteed, then the backup will fail and this might occur in a number of conditions:
-
The replica virtual machine isn’t healthy and is in a critical state.
-
The replica virtual machine is resynchronizing (in the Resynchronization in Progress or Resynchronization Required state).
-
Initial replication between the primary and secondary site is in progress or pending for the virtual machine.
-
.hrl logs are being applied to the replica virtual machine, or a previous action to apply the .hrl logs on the virtual disk failed, or was canceled or interrupted.
-
Migration or failover of the replica virtual machine is in progress
Top Third-Party Hyper-V Backup Products
It is impossible to use the Windows Server Backup if there are a lot of Hyper-V hosts and virtual machines. In this case you will have to choose one of the third-party solutions. You cannot say for sure that this or that product would be an ideal solution for Hyper-V backup since there are a lot of things to be considered. They include the number of hosts, licensing limitations, necessary features, network architecture, etc.
There are many commercial and free backup products in the market, and it is hard to choose the right one. Usually, Gartner magic quadrant is used to determine the niche leaders. I have found this image that shows the main players and leaders in the market of backup solutions for data centers in 2019.
As you can see, Gartner names the following companies and products among the leading providers of backup solutions:
- Commvault
- Dell EMC
- IBM
- Veeam
- Veritas Technologies (Symantec — Veritas Backup Exec)
- Actifio
- MIcroFocus (HPE Data Protector)
Особенности дедупликации
- Если дедупликация будет работать с дисками с объемом более чем 1 ТБ, то оптимизатор дедупликации будет использовать очень много памяти.
- Если дедупликация будет работать с сжатыми данными, но с объемом сжатого более чем 10 ТБ, то длительность работы оптимизатора дедупликации будет слишком большим. Такое может получиться, если просто копировать данные ежедневно на дедуплицированный диск в разные папки.
- Бэкапы на HDD хранить можно и даже нужно, а вот рабочие виртуальные машины хранить на HDD в количестве больше 5-10 не стоит. К дедупликации это относиться с той лишь стороны, что дедупликация таких рабочих виртуальных машин сведет производительность HDD в ноль.
Резервное копирование виртуальных машин
-
Настройте сервер MABS и хранилище. При настройке хранилища используйте следующие рекомендации по выделению емкости хранилища.
- Средний размер виртуальной машины — 100 ГБ
- Количество виртуальных машин на каждый сервер MABS — 800
- Общий размер 800 виртуальных машин — 80 ТБ
- Объем необходимого пространства для хранения резервных копий — 80 ТБ
-
Настройте агент защиты MABS на сервере Hyper-V или в узлах кластера Hyper-V.
-
В консоли администрирования MABS щелкните Protection (Защита) > Create protection group (Создать группу защиты), чтобы открыть мастер создания группы защиты.
-
На странице Выбор элементов группы выберите виртуальные машины, для которых необходимо обеспечить защиту, на серверах узлов Hyper-V, где они размещаются. Рекомендуется поместить все виртуальные машины, для которых задана одна политика защиты, в одну группу защиты. Для эффективного использования пространства можно включить совместное размещение. Совместное размещение позволяет размещать данные из разных групп защиты на одном диске или ленточном накопителе, с тем чтобы нескольким источникам данных был назначен один том реплики и точки восстановления.
-
На странице Выбор метода защиты данных укажите имя группы защиты. Выберите параметры Краткосрочная защита с использованием диска и Мне нужна оперативная защита , чтобы выполнить резервное копирование данных в Azure с помощью службы архивации Azure.
-
В разделе Выбор краткосрочных целей > Диапазон хранения укажите, как долго требуется хранить данные диска. В поле Synchronization frequency (Частота синхронизации) укажите, как часто должна выполняться добавочная архивация данных. Вместо выбора интервала для добавочных резервных копий можно выбрать параметр Непосредственно перед точкой восстановления. При этом MABS будет выполнять быструю полную архивацию непосредственно перед запланированной точкой восстановления.
Примечание
Если вы защищаете рабочие нагрузки приложения, точки восстановления создаются в соответствии с частотой синхронизации (если приложение поддерживает добавочное резервное копирование). Если это не так, MABS выполняет быструю полную архивацию вместо добавочного резервного копирования и создает точки восстановления в соответствии с расписанием быстрого резервного копирования.В процессе резервного копирования не выполняется резервное копирование контрольных точек, связанных с виртуальными машинами.
-
На странице Проверка выделения места на диске проверьте пространство на диске пула носителей, выделенное для этой группы защиты.
Общий размер данных обозначает объем данных, для которых вы будете создать резервную копию, а в разделе Дисковое пространство, которое нужно подготовить в MABS указывается рекомендуемое пространство для группы защиты. MABS выбирает идеальный том резервного копирования на основе параметров. Однако вы можете изменить выбор тома для резервного копирования в разделе Сведения о выделении места на диске. Для рабочих нагрузок выберите предпочтительное хранилище в раскрывающемся меню. Вы можете изменить значения для параметров Общий объем и Доступный объем в области Доступный объем на диске. Неподготовленное пространство — это объем хранилища, который MABS рекомендует добавить в том, чтобы обеспечить беспроблемное резервное копирование.
-
На странице Выбор метода создания реплики определите, каким образом будет выполняться начальная репликация данных в группе защиты. При выборе автоматической репликации по сети, рекомендуется указывать часы с наименьшей загрузкой. Для больших объемов данных или неоптимальных условий в сети лучше выбрать ручной режим, что подразумевает автономную репликацию данных с использованием съемных носителей.
-
На странице Параметры проверки согласованности выберите способ автоматизации проверки согласованности. Проверку можно выполнять, когда данные реплики становятся несогласованными или по расписанию. Если вы не хотите настраивать автоматическую проверку согласованности, ее можно выполнить вручную в любое время, щелкнув правой кнопкой мыши группу защиты и выбрав команду Выполнить проверку согласованности.
После создания группы защиты осуществляется начальная репликация данных в соответствии с выбранным вами способом. После начальной репликации каждая операция резервного копирования выполняется в соответствии с параметрами группы защиты. Если вам требуется выполнить восстановление данных из резервной копии, учтите следующее.
Backup and restore VMs using Windows Backup API
Advantages:
- Runs on the Hyper-V host, so no need to install and a setup client in each VM
- Your Hyper-V VM storage may support VSS (Volume Shadow Copy Service), so that the storage snapshots the VM (e.g. NetApp)
- Backup via the standard Windows Backup API
- Works with older Hyper-V versions (<2016)
Disadvantages:
- All your VMs get snapshotted and backed up all at once. You cannot have different backup frequencies for different VMs and because snapshots happen at volume level snapshot overhead is much larger if you have multiple VMs with IO
- If you do not have a changed block tracking (CBT) driver the client wiill have to read the whole virtual disks during each backup to find out what changed. The CBT driver works only with locally attached storage (not with remote storage or cluster shared volumes)
Conclusion: Only use if you have an old Hyper-V version (<2016) or if it is a necessity that you use the snapshot functionality of your VM storage.
How to setup:
Install the client on the Hyper-V host. Afterwards select “Configure components to backup” on the tray icon and configure the VMs to backup. You can also run then in a command window to get this selection screen.
How to restore:
Select “Restore components” on the tray icon and choose the time and VMs to restore, then restore. You can also run then in a command window to get this restore screen.
Резервное копирование — это просто
Продукт Altaro, известный ранее под названием Altaro Hyper-V Backup, нацелен на компании сегмента SMB. Именно поэтому разработчики постарались сделать его максимально простым и интуитивно понятным, но при этом обладающим всеми необходимыми малому и среднему бизнесу средствами. Выпущенная в прошлом году шестая версия продукта поддерживает резервное копирование ВМ и в среде Microsoft Hyper-V, и в среде VMware vSphere, поэтому называется он теперь Altaro VM Backup.
Его основные особенности:
- Поддержка Hyper-V в Windows Server 2008 R2 и старше.
- Поддержка VMware vSphere 5,6 и старше.
- Резервирование Exchange Server на уровне элементов.
- Технология инкрементного резервного копирования ReverseDelta.
- Репликация резервных копий на другую площадку.
- Сжатие данных, уменьшающее объем резервных копий примерно на 25%.
- Шифрование резервных копий.
- Мгновенное восстановление на уровне файлов.
- Восстановление в «песочницу» Sandbox Restore для проверки целостности резервной копии и самой возможности восстановить ее.
- Поддержка Microsoft Exchange и SQL.
- Полная поддержка Microsoft Cluster Shared Volumes.
- Возможность восстановления ВМ на разных системах.
- Индивидуальные, задаваемые для отдельных ВМ, политики резервирования и хранения.
Backup virtual machines (VMs) by installing the client in the VMs
Advantages:
- Equivalent setup to bare metal machines
- More fine grained backup configuration: You can combine image and file backups, exclude files from backup, more easily run commands before or after backup etc.
Disadvantages:
- Performance in VMs is slightly worse than bare metal performance. This also applies to backup software in the VM
- If there is no changed block tracking (CBT) driver installed it might be inefficient
- Separate setup/configuration for each VM. Need access to VM to install software on it
- VMs snapshot their storage themselves whereas it might be more efficient to let the Hyper-V VM storage (e.g. NetApp) handle the snapshotting (if present)
Conclusion: Preferred method if you already manage bare metal servers, have no problem installing software in the VMs or want have more fine grained backup configuration.
How to setup:
See 2.2 Client installation in the administration manual.
How to restore:
See 9 Restoring backups in the administration manual.
Back up virtual machines
-
Set up your MABS server and your storage. When setting up your storage, use these storage capacity guidelines.
- Average virtual machine size — 100 GB
- Number of virtual machines per MABS server — 800
- Total size of 800 VMs — 80 TB
- Required space for backup storage — 80 TB
-
Set up the MABS protection agent on the Hyper-V server or Hyper-V cluster nodes.
-
In the MABS Administrator console, select Protection > Create protection group to open the Create New Protection Group wizard.
-
On the Select Group Members page, select the VMs you want to protect from the Hyper-V host servers on which they’re located. We recommend you put all VMs that will have the same protection policy into one protection group. To make efficient use of space, enable colocation. Colocation allows you to locate data from different protection groups on the same disk or tape storage, so that multiple data sources have a single replica and recovery point volume.
-
On the Select Data Protection Method page, specify a protection group name. Select I want short-term protection using Disk and select I want online protection if you want to back up data to Azure using the Azure Backup service.
-
In Specify Short-Term Goals > Retention range, specify how long you want to retain disk data. In Synchronization frequency, specify how often incremental backups of the data should run. Alternatively, instead of selecting an interval for incremental backups you can enable Just before a recovery point. With this setting enabled, MABS will run an express full backup just before each scheduled recovery point.
Note
If you’re protecting application workloads, recovery points are created in accordance with Synchronization frequency, provided the application supports incremental backups. If it doesn’t, then MABS runs an express full backup, instead of an incremental backup, and creates recovery points in accordance with the express backup schedule.The backup process doesn’t back up the checkpoints associated with VMs.
-
In the Review disk allocation page, review the storage pool disk space allocated for the protection group.
Total Data size is the size of the data you want to back up, and Disk space to be provisioned on MABS is the space that MABS recommends for the protection group. MABS chooses the ideal backup volume, based on the settings. However, you can edit the backup volume choices in the Disk allocation details. For the workloads, select the preferred storage in the dropdown menu. Your edits change the values for Total Storage and Free Storage in the Available Disk Storage pane. Underprovisioned space is the amount of storage MABS suggests you add to the volume, to continue with backups smoothly in the future.
-
On the Choose Replica Creation Method page, specify how the initial replication of data in the protection group will be performed. If you select to Automatically replicate over the network, we recommended you choose an off-peak time. For large amounts of data or less than optimal network conditions, consider selecting Manually, which requires replicating the data offline using removable media.
-
On the Consistency Check Options page, select how you want to automate consistency checks. You can enable a check to run only when replica data becomes inconsistent, or according to a schedule. If you don’t want to configure automatic consistency checking, you can run a manual check at any time by right-clicking the protection group and selecting Perform Consistency Check.
After you create the protection group, initial replication of the data occurs in accordance with the method you selected. After initial replication, each backup takes place in line with the protection group settings. If you need to recover backed up data, note the following:
Supported scenarios
MABS can back up virtual machines running on Hyper-V host servers in the following scenarios:
-
Virtual machines with local or direct storage — Back up virtual machines hosted on Hyper-V host standalone servers that have local or directly attached storage. For example: a hard drive, a storage area network (SAN) device, or a network attached storage (NAS) device. The MABS protection agent must be installed on all hosts.
-
Virtual machines in a cluster with CSV storage — Back up virtual machines hosted on a Hyper-V cluster with Cluster Shared Volume (CSV) storage. The MABS protection agent is installed on each cluster node.
Основные требования к средствам резервного копирования ВМ Hyper-V
Это в общих чертах о резервном копировании Hyper-V, но на деле возникает куча нюансов и проблем. Попробую перечислить наиболее распространены проблемы:
- Чем дольше средство резервного копирования забирает снапшот (бэкап) к себе, тем больше изменений накапливается в дельта файлах. При достаточно большом количестве изменений внутри ВМ за время копирования файлов, процесс слияния файлов при удалении снапшота может вызывать высокую нагрузку на диски, Hyper-V хост и саму ВМ. Т.е. желательно максимально быстро забрать снимок. В Hyper-V Server 2016 для ускорения процесса резервного копирования используется технологий Resilient Changed Tracking, которая позволяет средству резевного копирования копировать только блоки данных, измененные с момент последнего бэкапа. При этом не нужно «забирать» ВМ целиком.
- При копировании данных снимка ВМ по LAN сети с хоста Hyper-V на хранилище резервных копий возможно вызвать высокую нагрузку на сеть. Поэтому для трафика резервного копировании желательно использовать отдельный интерфейс сервера, или же копировать данные через SAN сеть.
- Исходя из вышестоящих пунктов при использовании внешних систем хранения для хранения файлов ВМ, вы можете воспользоваться возможностями СХД по интеграции со средствами резервного копирования (аппаратные снапшоты).
- Изначально гостевая ОС не подозревает о том, что создается ее резервная копия. Соответственно при попытке восстановить ВМ из такого бэкапа, ОС пытается продолжить свою работу с момента создания снимка. В некоторых случаях это может вызвать проблемы как с самой ОС, так и с потерей данных в запущенными внутри нее приложениях (особенно в транзакционных, таких как Exchange, SQL, ADDS и т.п.). Для преодоления этой проблемы в Hyper-V 2016 появился новый тип снимков — Production Checkpoints (Microsoft рекомендуется применять обычные снимки — Standard Checkpoint только в тестовых и лабораторных средах, или для бэкапа остановленных виртуальных машин). Производственные снимки работают за счет наличия в гостевой ОС средств интеграции Hyper-V и основываются на технологии Volume Shadow Copy (Windows) или заморозки файловой системы fsfreeze (Linux). Однако состоянии памяти при этом не копируется. Т.е. Hyper-V уведомляет гостевую ОС о создании снимка, приложение с поддержкой VSS корректор завершает текущие транзакции, переходит в консистентное состояние и создается снимок ВМ. При восстановлении из такого снимка гостевая ОС выключена (т.к. состояние памяти не сохранялось), после включения она считает, что просто произошло аварийное отключение по питанию. Приложение (если оно поддерживает VSS) при этом начинает работу с сохранённого согласованного состояния.
- Для хранения бэкапов виртуальных машин нужно достаточно много места. Чем чаще вы делаете снимки и чем дольше должны хранится бэкапы, тем больше места вам нужно в хранилище резервных копий. Как правило вам на помощь может прийти технология дедупликации данных (встроенная в Windows Server) или собственная технология от вендора средства резервного копирования. Если вы используете дифференциальные диски, нужно чтобы средство резервного копирования поддерживало эту технологию. Иначе вы можете хранить одинаковые данные ВМ несколько раз.
- При большой плотности виртуальных машин на хосте желательно иметь возможность планирования времени резервного копирования ВМ, чтобы избежать чрезвычайно нагрузки на продуктивные системы в производственное время.
- Если вам нужно хранить несколько копий виртуальной машины на несколько дат несколько дней, нужно обеспечить управление количеством хранимых копий ВМ, автоматизировав управление резервными копиями скриптами или средствами программы резервного копирования.
- Также важны средства мониторинга создания резервных копий. Не хочется в определенных момент узнать, то резервное копирование не работает, т.к. на СХД под бэкапы уже давно кончилось место. Здесь же нужно вспомнить про средство верификации резервных копий.
- Довольно часто нужно восстановить из резервной копии виртуальной машины конкретный файл. Некоторые средства резервного копирования / восстановления позволяют выполнять гранулярное восстановление файлов / папок без необходимости развёртывания целиком ВМ или ее виртуального диска.
Далее мы рассмотрим несколько популярных решений по организации резервного копирования ВМ на Hyper-V с точки зрения рассмотренных возможностей.
Заключение
На этом все. Единственное замечание — я не тестировал падение производительности во время выполнения бэкапа. На глаз я не заметил никаких тормозов в работе виртуальных машин. Но они у меня все ненагруженные были. Время выполнения бэкапа каждой машины значительное. Но, конечно, оно зависит от множества факторов.
Есть хорошая возможность совместить HVBackup и бэкап серверов с rsync. Например, делать архивы локально на сервере с hyper-v, монтировать к linux серверу папку и с помощью rsync забирать zip файлы с виртуальными машинами. Либо сразу делать резервное копирование на линуксовую самбу, к примеру. По приведенной выше ссылки есть пример на эту тему.
Несмотря на то, что среда Hyper-V предоставляет довольно много технологий обеспечения высокой доступности и отказоустойчивости виртуальных машин (таких как кластера, Live Migration, репликация, и т.д.), администратору необходимо думать о классическом резервном копировании виртуальных машин. Все эти технологии позволяют минимизировать время недоступности ВМ в различных сценариях, но не обеспечивают возможность восстановления в случаях различных форс мажоров, таких как природные катаклизмы, ошибки персонала, хакерские или вирусные атаки, атаки конкурентов и подобные сценарии. В этой статье я постараюсь рассмотреть основные требования, которые предъявляются к системам резервного копирования Hyper-V, стратегии резервного копирования и возможности бесплатных и коммерческих продуктов резервного копирования.
Вы можете создавать резервные копии виртуальных машин, запущенных на хосте Hyper-V, с помощью встроенного Windows Server Backup (или скриптов на его основе, запускаемых через wbadmin), бесплатных или коммерческих продуктов. Всех эти способ объединяет то, что в основе резервного копирования виртуальных машин Hyper-V лежит технология снапшотов (или снимков). В снимке хранится как состояние виртуальных дисков, так и содержимое памяти и настройки виртуальной машины. Т.е. снапшот представляет собой состояние виртуальной машин на какой-то момент времени.