Save to My DOJO
Virtualization is becoming ubiquitous today as more and more companies realize the benefits of Hyper-V. But as a line of business apps and mission-critical functions are moved from physical hosts to virtual ones, the idea of using “snapshots” to take backups of VMs is simply not enough. They don’t scale, can be confusing to work with, and consume resources much better left for running the production VMs. In this article, we’re going to look at what you want to do to provide a scalable and performant backup solution for your Hyper-V virtual machines running on Microsoft Windows Server 2012, 2012 R2, 2016, and 2019 hosts.
Why Backing Up VMs is Different
It’s important to understand that, while a virtual disk is, at least to the host operating system, a single big file, it’s definitely not just a single big file. Even a simple VM with a single disk for everything has an image of a system volume, with the full directory structure you’d find on any system, along with supporting files for the image, changes, et al. More advanced VMs may also include other image files on other storage arrays to handle databases, or log files, or to host the applications that the VM runs. All of these are likely to be in a constant state of reading and write while the VM is running. When a virtual machine is shut down, you can treat that data like a handful of really big files, but who wants to shut down mission-critical servers every night so you can make a backup? Anybody?
In addition to all the changes going on within the VM’s file systems, which are all reads and writes to that big file, there’s the memory image being written to the swap file of the VM, which is again a bunch of changes being written to that one big file. Trying to “grab” an image of a file that is in an almost constant state of change is what makes backing up VMs so different from backing up files. A file system can be held off from committing a change to disk when a backup application puts a lock on a file to capture it to back up in a second or two, but you cannot do that when you’re trying to back up a virtual disk that may take several minutes to complete. That virtual machine is wanting to write multiple changes per second and cannot just stop when it’s running. And you can’t shut down VMs each night just so you can do backups. If you have multiple machines behind a load balancer, you can take one at a time out of rotation to back things up, but that increases complexity, reduces performance, and risks fault tolerance.
There’s also the method to consider. Physical device backups require software to be running on the host machine or access to the host’s storage over a network share. Running the software on the host may be okay in smaller environments but is not advisable. You want to preserve as much as possible of the host’s resources as you can for the VMs to use. Agent-based backups use a small software service to run on the VM host, while the heavy lifting of the backup application handling things like compression, encryption, deduplication, and the actual jobs of backing up VMs is handled by a server separate from your VM hosts.
Choosing the right application
There are several applications on the market that can do backups of virtual machines, but not all have all of the key features you want to have to protect your mission-critical systems. Here is the shortlist of must-have features you need to have in order to get the best performance and protection for your VMs in the most cost-effective way you can.
- Live backups
Make sure your backup solution can do backups while the VM is running. Not shut down, not paused, not taken out of the load balancer rotation. Backups should help protect you, not slow you down. Live backups mean you can back up when you want without dropping capacity or staying up late at night.
- Continuous Data Backups
How many changes a day do your VMs process? 10? 1000? 1M? How much work would it take to bring a machine and its config back to “current” if you had to start from a backup taken last night? Continuous Data Backup lets you backup your VMs throughout the day-as frequently as every five minutes if that’s what you need. That’s a pretty good RPO.
Backing up multiple times a day is great for RPO but will need a LOT of storage space to do. Save space by choosing a backup solution that can do deduplication and make sure it can do it inline, not after the fact.
- Automatic Retention Policies Further help keep your storage use in line by choosing a solution that handles retention policies automatically. You don’t have time to go through and dump old backups. Your solution should do that for you.
- Historical Point-in-Time Options There are benefits to keeping some older backups for recovery, analysis, and other just-in-case scenarios. Systems that can take and keep yearly or quarterly or monthly or weekly backups so you have a historical point you can go back to is invaluable. Frequently called a “Grandfather-father-son” rotation scheme, make sure your solution can take care of this for you.
Even with fast backups that can run while the VMs are live, you don’t have time to do backups serially. Unfortunately, some solutions can only do one VM at a time. Make sure the one you choose offers concurrency so you can back up multiple machines all at once.
- Options options options
You want options on where your backups go. Disk to disk is okay but can be costly, and if they are all in the same place, a site disaster means you’re toast. Over the wire to an offsite location is much safer, but of course, it requires that you have an offsite location. If you don’t have a second datacenter, make sure your solution supports cost-effective and secure data storage. Azure Blob Storage is a great solution offering secure storage, fault tolerance, and quick recovery, so consider a solution that can use Azure for storing your backups.
Crash Course on VSS (Brief)
We mentioned in the features section live backups. How do you take a backup of a VM that is currently running? Easy. Use a solution that works with VSS. The Volume Shadow Copy Service, or VSS, is where the magic happens. This service, a part of all currently supported versions of the Windows operating system and dating back to Windows XP, enables the operating system and compatible applications to take backups of volumes while other applications or services are actively writing data to them. That’s critical to obtaining consistent and complete backups of large data sets, including databases, complete volumes, and virtual disks. VSS coordinates all the actions needed to create a “shadow copy,” also called a snapshot, of whatever data is being backed up. VSS is useful for more than just backups. You can use it for data mining, disk-to-disk backups, fast data recovery for failed LUNs, and more. In the case of VMs, using VSS to create backups ensures that you get everything that makes up the virtual disk so that you have an application-consistent backup. That way, you have a working VM you can boot if you need to, not just a VHD you can mount to search the file system.
There are four parts of VSS. They include
- The VSS service, which is a part of Windows and arbitrates the communications between the various other components
- One or more VSS requestors, which are the backup applications to use VSS. These include the Windows Server Backup Utility (Windows Backup,) System Center Data Protection Manager and many third-party backup software solutions.
- The VSS writers, which are the components that guarantee that data is complete and consistent when committed to a volume and made available for backup. Microsoft server products like Exchange and SQL Server and, yes, Hyper-V, include VSS writers, as so some third-party server applications that need to rely on VSS.
- The VSS writer, which is what handles the shadow copy creation and maintenance. This can be software in the operating system or in drivers or can be a hardware solution included in a SAN. Windows’ included VSS writer uses a copy-on-write to ensure all writes are committed to a shadow copy.
VSS writers can write data for shadow copies in three different ways.
- Complete copy – consider this a clone. Every single block at a given point in time is copied to another volume.
- Copy on write – this creates a differential copy of all changes (writes) from a given point in time going forward.
- Redirect on write – similar to the copy on write. This redirects all changes to a different volume.
Please see https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee923636(v=ws.10) if you would like a deeper dive into VSS, including information on I/O and storage costs as well as different providers that are available. For the purposes of backing up Hyper-V virtual machines, it’ enough to understand that you want a VSS-compatible backup solution so that you can take exact point-in-time backups as and when you need it.
What are Production Checkpoints? (2016 & 2019)
Hyper-V in Windows Server 2016 introduced a new type of checkpoint, called the Production Checkpoint. The original checkpoint is now referred to as a “standard checkpoint”. The Production Checkpoint is a point in time image of VM and leverages the guest operating system’s backup technology to take a complete snapshot of the VHDX at the point in time. Not only is this faster than using a saved state technology, but it’s also fully supported to restore this image for all production workloads, which is a pretty big deal for things like Exchange, SQL, and Active Directory. Standard checkpoints rely upon the host and “grab the state, data, hardware settings, et al” of a running VM but are not supported for production recovery. You can use them for dev and test all you want, but don’t count on them for production if you need to maintain a supported state.
What is Resilient Change Tracking (aka CBT), and why is it Important?
Changed Block Tracking (CBT,) or as Microsoft refers to this, Resilient Change Tracking, is a native change tracking mechanism in Hyper-V 2016 and onward. This is a more flexible and better-performing method of capturing changes to a volume than VSS offers and is a feature VMware admins have enjoyed for a few years. RCT’s most important capabilities are the ability to track and capture changes at the block level, which speeds up performance and can save 30% or more on storage requirements when taking backups of VHDXs. That equates to cost savings for storage.
Use case of a non-VM based VM Backup tool vs. something like Altaro VM Backup.
When it comes down to what solution to use to backup (and restore) your mission-critical virtual machines, you can use any system that can back up files stored for Hyper-V VMs, including the VHDXs, differencing files, configuration files, and memory dumps. If you store all of those in a single location, you can just back up the directory, and Bob’s your uncle. What’s not to love? Actually, quite a bit. There are several to consider. Let’s take a look at a hypothetical organization that runs a mission-critical web application with a three-tier architecture. The front-end web servers, middle-tier application servers, and back-end database servers all work together and all have different backup needs, RPO/RTO targets, and retention requirements. All are running as Windows Server 2016 (in this case but would work with other supported versions) guests on various Hyper-V hosts.
- Storage requirements-Using Windows Backup or a third-party backup application means taking backups of every single machine in all three tiers. Even though they are all running the same operating system and at the same patch level, each VM is a unique set of files. But when using Altaro VM Backup can reduce storage costs by performing inline deduplication. Since the VMs are running, and the solution is leveraging the guest operating system, files that are common amongst the VMs, like the operating system, can be deduplicated in the backups, saving tons of space.
- Reduced RPO-Backups of files can take a significant amount of time to start, run, and complete, increasing the elapsed time between your most recent backup and when something bad happens. Continuous Data Protection enables you to take a backup as frequently as every five minutes, ensuring a very short RPO. And that policy can be set at different frequencies for different VMs easily. Take a backup of the web servers once a day, the middle-tier servers four times a day, and the database servers every five minutes, to get a balance between RPO and storage costs.
- Simplicity-many backup applications are written for file systems and don’t have as much granularity for different needs for different sources, making the setup and maintenance of backups much more work. Altaro is purpose-built to backup virtual machines, and the interface is easy and intuitive, letting you get your backups set quickly.
An Example Backup Job
Still not convinced? Here’s a quick walkthrough of how quick and easy it is to set up a backup of a VM using Altaro, complete with pretty pictures. We’re using our own product as an example here, but many other backup applications targeting virtual machines will work in a somewhat similar manner.
- If you haven’t already, log onto your Hyper-V host, download and install Altaro Backup fromhttps://www.altaro.com/vm-backup/download.php. You can choose a free version that lets you back up two VMs per host forever or a thirty-day trial that lets you try everything for a month before you buy. It’s a “next, next, enter” type install. At the end of the install, you will be prompted to launch the management console like this.
- The console will prompt you to either connect to “This Machine” or to a “Remote Machine” since you can manage more than one instance of Altaro VM Backup from the same console. Choose “This Machine” to set up your job. You can also tick the box to log on automatically next time if you wish.
- You can use the Quick Setup to get a backup job up and running quickly. As you can see in the console, there are three simple steps.
- Click Add Hyper-V/VMware Host to add your host physical server. This will switch to the management console once it enumerates the host.
- Select the backup location you wish to use to store your backups. You can select local or network storage, as seen below.
In this example, we will use a Physical Drive, so we click that and then click Next.
- Here we can see the three physical disks connected to our Hyper-V host, and we have selected the G: drive. Note, backups will be stored at the root of the volume, under a folder names AltaroV7, unless you click the “Choose Folder” to pick or create another folder.
To complete step 2, we just need to select the drive and click Finish.
- Now we need to select the VM or VMs we wish to backup to this drive and simply drag-and-drop them to the drive. Make sure you drag the VMs over the actual drive letter, not just into the middle pane.
You can see in the console pane on the left that there are several options you can configure, including scheduling, retention, and more. For a quick backup, though, we’re just going to click down on Step 3, Take Backup.
- You will be prompted to save changes. Do so, then tick the box next to the VMs you wish to back up and click “Take Backup.”
- Please note, if you have VMs that were created on an older version of Hyper-V, they might be running configuration version 5.0. If you get an error that they cannot be backed up, you need to first shut down the VM, then update the configuration (right-click the VM in the Hyper-V console and select upgrade) and then restart the VM. You’ll be able to back it up then.
- As the backups run, you can see the status by moving your mouse over the progress icon.
- When complete, you should see this.
If you click the + sign on the far right, you’ll see some statistics on the backup. Notice the space savings for this particular backup!
If you need to do a restore, the steps are very similar.
- On the right-hand menu, click Restore.
- Click the source location, and click Next.
- Select the VM or VMs you want to restore, and click Next.
- Choose the options appropriate for your restore job. Notice you can restore to another host, and the default is to restore with the NIC disconnected. Click Restore, and off it goes!
There are several other options you can select. You can do granular file-level restores from file servers or item-level restores from Exchange servers.
You can also test and verify your backups, which is probably the single most important thing to do with any backup solution but is missed by so many other systems. The very last thing you ever want to do is find out your backups are not working only when you actually need to do a restore!
One other thing you may want to make sure you look at is the Reports section. It gives you just what you need to check and confirm operations completed successfully, without burying you in details you won’t want to read anyway. It tells you the what, when, and how, and that things were successful, or if something wasn’t, why.
You cannot export the reports, but you can see everything you need. If the boss wants a printout, screenshots of the console should suffice.
Setting up scheduled backups and retention policies are both simple drag and drop operations. Pick a default schedule or create your own, drag the VMs to it you want to be covered, and that’s it. It will take you longer to read this paragraph than to set up a backup and retention schedule!
If your business relies upon virtual machines, then you need backups that you can rely upon. Altaro VM Backup gives you all the functionality you need to backup, and restore VMs and individual items from VM backups with the security and flexibility every business needs, without the costs that only enterprises can afford. You owe it to yourself to get the peace of mind that Altaro VM Backup offers by downloading and installing it today.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!