From a systems management point of view, you should treat VMs as if they were physical machines, with some exceptions. When it comes to backup and restore, there are some special issues to consider. If you look at a Hyper-V host machine running a number of VMs, you may won- der whether you can back up all of that in one go. In the ideal world, you could do the following:
Back up all VMs, and do so incrementally.
•u
Make all VMs aware of the backup so that they can do the right thing on restore. This is
•u
particularly important for Active Directory and Exchange. Restore VMs individually.
•u
Figure 29.41 The starting point for Hyper-V con- figuration files. All files here are symbolic links, pointing to the physical location of the XML files that define virtual machines.
In principle you could do it this way. The reality is different, however. We’ll review briefly how a modern Windows backup works.
Since the days of Windows 2003, we have had Volume Shadowcopy Services (VSS). This component does two things for the backup process. First, it can freeze a disk volume, take a snapshot, and unfreeze the disk again. The snapshot stays on the volume. It works using a dif- ferencing algorithm and takes little space. Second, the VSS service interacts with applications during the backup to allow them to clean up and prepare, such as flush buffers, stabilize data structures, and so on. You can see how this benefits complex applications. VSS allows them to be backed up quickly and with data structures intact. Such applications would be Active Directory, SQL Server, Exchange Server, and of course…Hyper-V.
So, to make VSS work in a virtual environment, you need a VSS provider for Hyper-V and a component in the VM that integrates with this provider. How else would the applications in the VM be aware that there is a backup going on? In other words, it’s a two-stage rocket: the VSS pro- cess in the host needs to trigger the VSS process in the VM during backup, using the Hyper-V VSS provider as the communication channel. In the VM itself, it’s the Integration Services that takes care of the integration. This is an important point to note: without working Integration Services, you cannot have a real backup from the host. Yes, using VSS you can back up the .vhd files that make up the VM, but the VM will not be aware of the backup. It would be nothing better than a live image backup with all its limitations.
Let’s recap. You have two options to back up operating systems and applications in a VM: Run a backup from the host, using a backup tool that is VSS aware. The Integration Services
•u
in the VM are required.
Treat the VM as a physical machine, and run backups software from the virtualized OS.
•u
There is a lot going for the second option. It will fit right it with your existing backup system, it won’t break anything, and you know how to do it. This way, the host can be a black box that can be replaced at will. Be aware that a backup initiated from a VM generates a lot of disk I/O. If you have 10 VMs on one host all doing their backup at the same time, you generate 10 times the load on the host. It takes pretty good hardware to keep up with that!
On the other hand, backing up all those VMs in one shot is attractive as well, so let’s take a look at that. The built-in tool for the job is Windows Server Backup. There is one problem you need to take care of before you start. By default, Hyper-V is not registered with VSS. If you made a backup now, the VSS service in the VMs would not be used. The following steps show you how to install WSB and to register the Hyper-V VSS provider. For more details, please read Knowledge Base article 958662.
1.
Start Server Manager, select Features, then select Add Features. Find Windows Server Backup Features, select all subfeatures, and install it.2.
Start the registry editor, regedit.exe. Browse to HKLM\SOFTWARE\Microsoft\Windows NT\ CurrentVersion.3.
Create a new key called WindowsServerBackup.4.
Below this key, create a new key called Application Support.5.
Below this key, create a new key called {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}. Yes, we’re serious. This is the GUID corresponding to the Hyper-V VSS writer. Don’t forget the curly brackets.6.
Below this key, create a new REG_SZ value called Application Identifier.7.
Set this value to Hyper-V, as shown in Figure 29.42.If you are going to do this more than once, you will probably want to export this key into a .reg file. There is no need to reboot. Windows Server Backup looks for VSS registrations every time it starts.
To get all VMs and their configuration, you must back up all volumes where you have the VMs, as well as the system volume that stores the Hyper-V configuration. In most cases, the best thing is to back up all volumes except the one that will hold the backup files. For this example, you’ll to do a one-time backup to a local USB drive:
1.
From the Administrative Tools, start Windows Server Backup. In the Actions pane, select “Backup once.”2.
On the first screen, just click Next for Different Options.3.
Select Custom, and click Next.4.
Add Items, and select the system partition (C, most likely) and all partitions containing VMs.5.
Click Next to select the destination drive. This can be a local drive or a remote share.Figure 29.43 shows the summary screen.
6.
Click the Backup button to start the process. Figure 29.42Required registry setting to regis- ter the Hyper-V VSS writer with Windows Server Backup Figure 29.43 Windows Server Backup, about to start the Hyper-V backup
Although this is clear enough, the restore process is not nearly as nice. WSB offers no way to restore individual VMs. Either you can restore all the Hyper-V configuration and data or you need to hand-pick the VHD files you want recovered. Still, the full restore is good enough in a disaster recovery situation where the whole host is lost and you need to recover the VM setup. If that is your main purpose, you are all set!