Hyper-V Backup – Considerations when Backing Up Virtual Machines
Making proper backups on virtual machines can be a little different than backing up physical hardware. Specifically, backing up VM’s on Hyper-V with Windows Server Backup requires some special considerations. This article will provide a brief overview on what needs to be considered to properly backup a virtual machine on Hyper-V. Before you proceed with the process of backing-up virtual machines by using Windows Server Backup and VSS, make sure that you are aware of the following considerations:
It’s an all or nothing situation
You must perform a VSS snapshot of the entire volume on which the VMs are stored. You cannot select individual folders or files from within Windows Server Backup, although the UI may seem to let you select them.
Also, partial backups are not supported. If any VM fails to create a snapshot, no VMs will be backed up.
Location of the VM configuration files and disks
When you perform a backup of the virtual machines, you must back up all volumes that host files for the virtual machine, including the InitialStore.xml file and the volume(s) containing the VHD(s) and configuration XML files. This means that if virtual machine configuration files are stored on D:, the virtual machine virtual hard disk (VHD) files are stored on E:, and the InitialStore.xml file is stored on C:, you must back up the C:, D: and E: volumes. This is why I strongly advise to configure the default location of the VM files and make sure all VMs use the same standard.
Hyper-V integration components must be installed and functioning in each running VM. You can verify that the Backup Integration Service is installed and running in each VM through the Hyper-V or SCVMM console.
Virtual machines that do not have Integration Services installed will be put in a saved state while the VSS snapshot is created. So will virtual machines that are running operating systems that do not support VSS. To read more about Integration Services importance in the context of backups please read this article:
Format the Volumes that contain the VHD files with 16-KB Blocks
It is strongly recommended by Microsoft that you use a 16-KB or larger cluster allocation unit size. The reason for this is that:
The System Shadow Copy provider uses a copy-on-write mechanism that operates at a 16-KB block level. This is independent of the file system’s cluster allocation unit size. If the file system’s cluster size is smaller than 16 KB, the System Shadow Copy provider cannot easily determine that disk defragmentation I/O is different from typical write I/O, and performs a copy-on-write operation. This might cause the Shadow Copy storage area to grow very quickly.
If the file system’s cluster size is 16 KB or larger, the provider can recognize disk defragmentation I/O and handle it correctly.
Using Dynamic Disks in VMs
Virtual machines that make use of dynamic disks cannot be backed up via VSS. Virtual machines that contain dynamic disks must be backed up offline. This means that running VMs with dynamic disks will force you to save the VMs before backing them up. Generally, as a best practice for performance, it is advisable to use fixed-size disks instead of dynamic disks.
Also, all disks must be formatted New Technology File System (NTFS).
Pass-Through Disks on VMs
If you use pass-through disks for the data disks on your VMs, remember that data that is stored on these disks cannot be backed up by the Hyper-V VSS writer.
Failover Clusters and CSV
You cannot use this method to back up failover clusters that use Cluster Shared Volumes (CSV volumes). Windows Server Backup does not support backing up Hyper-V virtual machines on CSV volumes. For that you’ll need to use dedicated backup software.
iSCSI LUNs on VMs
If you use remote storage devises and connect to the LUNs on these storage devices by using iSCSI directly from within the virtual machine’s operating system, remember that these cannot be backed up by the Hyper-V VSS writer. Thus, if you have separate iSCSI connections in your VM to remote storage, you’ll need to make sure that you take measures to back up that data either directly off your storage, or by using a backup client in the virtual machines themselves as though they were physical machines.
Using Remote Folders for Backup Destination
It is possible to use either locally-attached disk(s) or remote shared folders for your backup destination. If you save a backup to a remote shared folder, the backup will be overwritten if you use the same folder to backup the same computer again.
In addition pay attention to this: If the backup operation fails, you may end up with no backup because the older backup will have been already overwritten, but the newer backup will not be usable. Try to use sub folders in the remote shared folder to organize your backups.
As you can see, there is a completely different set of challenges when backing up virtual machines. When backing up on Hyper-V it’s important to keep these challenges and considerations in mind to ensure complete and usable backups that can minimize data-loss if something does happen to go wrong. Hopefully this article prepares you to start making your hyper-v backups.
More in Backup & Storage
Reviewing Your Backup Checklist
Apr 8, 2022 | Michael Otey
Cloud NAS Shootout: Amazon EFS/FSx versus Azure Files
Apr 4, 2022 | Arian Modiramani
Get Ready for AWS Pi Day 2022
Mar 10, 2022 | Michael Otey
Amazon Adds AWS Backup to S3
Feb 24, 2022 | Michael Otey
Disaster Recovery for Kubernetes
Jan 24, 2022 | Michael Otey
Big Announcements at AWS re:Invent 2021
Dec 2, 2021 | Michael Otey
Most popular on petri