Live Backup Changes in Hyper-V Server 2012 R2

Quite some time ago, we wrote a post about taking live backups in Hyper-V. Hyper-V Server 2012 R2 really changed the mechanics of backup. This post examines how those changes have affected live, or hot, backups.

Until 2012 R2, backup was strictly based on VSS (Volume Shadow Copy Service) operations. Backup applications trigger VSS in the host. For standard backup operations of the file system, VSS responds by flushing buffers and pausing I/O. It also notifies any applications that had registered with VSS that a backup was about to occur, granting those applications the ability to perform any additional preparations necessary. One such application is Hyper-V.

Hyper-V in these earlier versions would simply use the Integration Services, specifically the backup service, to notify the guest’s VSS of an impending backup operation. It would perform the same operations as VSS in the host by preparing its own operating system and registered applications for a backup.

Once everything is prepared, the earlier versions would just use the standard VSS approach, which was to take a VSS snapshot. This redirects new I/O to a temporary location so that backup operations are free to read from the source without disturbing ongoing operations. Once the backup is complete, everything returns to normal.

What’s new in 2012 R2 is that instead of using the VSS snapshot system, Hyper-V relies on its on snapshot system, which is gradually being renamed to “checkpoints”, ostensibly to avoid confusion with the VSS system. Instead of placing the new I/O in the System Volume Information tree the way that a standard VSS backup does, Hyper-V creates AVHD(X) files for the backup to use. For standard Windows guests, you won’t see any effective changes. Guests that don’t use backup services will have a great deal of change, assuming your backup program knows how to work with the new system. Sadly, a great many still don’t, even though this has been publicly available for over a year and was in public beta for a time before that. If you’re having trouble with getting live backups of your guests, it might be time to look into getting a new backup application.

For this posting, we’re going to take a look at some of the operations that would have been problematic for a live backup in 2012 and earlier. We’re going to use Altaro Backup for Hyper-V, since it works just fine with the new checkpoint system and since this is an Altaro blog.

Windows Guests with Dynamic Disks

In 2012 and earlier versions, it was impossible for a live backup to be taken of a guest with Dynamic disks. By Dynamic, I don’t mean dynamically expanding VHD(X) files; dynamically expanding disks are, and always have been, backed up using the same rules as fixed VHD(X) files. Rather than use a lot of words to explain what I’m talking about, here’s a screenshot of Disk Management inside my test system:

Before, this virtual machine would be saved while it was backed up because the E: drive is Dynamic. As a 2012 R2 guest, it continues running. During my test, the virtual machine did stop accepting input through the virtual machine console for a few moments, but Hyper-V Manager never changed the status of the VM from “Running”. Keep in mind that my test system is quite low-powered, so I’m not sure how big of a deal to make of the brief interruption. Importantly, the uptime counter of the machine was not reset, so this is considered a “live” backup.

I was not able to definitively answer my second question, which is, is VSS in the guest triggered for the contents of that Dynamic volume? Documentation on previous versions said that it would not be, but that was because the virtual machine would have been in an offline state during the backup and unable to receive messages from anything. Since the virtual machine stays online now, it should be receiving the VSS request through the Integration Services. The Dynamic disk is listed as eligible for VSS operations:

Furthermore, an AVHD(X) file is created for the Dynamic disk just like the Basic disk:

I don’t have any method to really test this, but the evidence at hand seems to indicate that virtual machines with Dynamic disks will now be backed up online, as long as your backup application supports the new features of 2012 R2.

Windows Guests With Disabled Integration Services

The next thing I did was disable the Integration Service for backup and try another backup. It worked just the same as it did in the previous test. Of course, its contents would be backed up in crash-consistent rather than application-consistent fashion as it has no way of knowing that a backup is occurring.

Linux Guests

There’s really good news if you’ve got Linux guests… or, at least as good as it’s likely to get. Backup for Linux guests in 2012 R2 works the same way that it does for Windows guests with the backup Integration Service disabled. I tested this with the current version of Altaro Hyper-V Backup (4.1.40.0). The backup worked without any interruption at all, even without selecting the “Enable Hot Backups for this Non-VSS Aware Guest VM”. When I did a restore, the data was in a crash-consistent state. Linux doesn’t have anything like VSS at this time, so this is the best that can be expected. The big thing here is that, as long as your backup application is fully compliant with the new backup system of 2012 R2, backups of Linux guests will automatically be live.

Application-Consistent vs. Crash-Consistent

If you’re not familiar with these terms, some of the first articles I ever wrote for Altaro described the difference in detail. The shorter version is that “crash consistent” means that the backup will be in the exact same state that it would be if the backed up machine had simply had its power removed at the moment that the backup was taken. Anything that was in-memory at the time would be lost. This is especially problematic for database systems that don’t have protections against that sort of thing, and still means data loss for those that do. Under Windows, these applications have the ability to register with VSS. When a VSS operation occurs, it notifies these applications so that they can prepare for the event. This usually involves clearing all pending operations. This way, when the backup occurs, there will be no activities in memory that can be lost. This style of backup is called “application consistent”.