Information and announcements from Program Managers, Product Managers, Developers and Testers in the Microsoft Virtualization team.
This blog post covers the scenarios and motivations that drive the backup of a Replica VM, and product guidance to administrators.
Ever since the advent of Hyper-V Replica in Windows Server 2012, customers have been interested in backing up the Replica VM. Traditionally, IT administrators have taken backups of the VM that contains the running workload (the primary VM) and backup products have been built to cater to this need. So when a significant proportion of customers talked about the backup of Replica VMs, we were intrigued. There are a few key scenarios where backup of a Replica VM becomes useful:
Thus various customer segments found that the backup of a Replica VM has value for their specific scenarios.
A key aspect of the backup operation is related to the consistency of the backed-up data. Customers have a clear prioritization and preference when it comes to data consistency of backed up VMs:
And this prioritization applied to Replica VMs as well. Conversations with customers indicated that they were comfortable with crash-consistency for a Replica VM, if application-consistency was not possible. Of course, anything less than crash-consistency was not acceptable and customers preferred that backups fail rather than have inconsistent data getting backed up.
Typical backup products try to ensure application-consistency of the data being backed up (using the VSS framework) – and this works out well when the VM is running. However, the Replica VM is always turned off until a failover is initiated, and VSS is unable to guarantee application-consistent backup for a Replica VM. Thus getting application-consistent backup of a Replica VM is not possible.
In order to ensure that customers backing up Replica VMs always get crash-consistent data, a set of changes were introduced in Windows Server 2012 R2 that failed the backup operation if consistency could not be guaranteed. The virtual disk could be inconsistent when any one of the below conditions are encountered, and in these cases backup is expected to fail.
These are largely treated as transient error states and the backup product is expected to retry the backup operation based on its own retry policies. With 30 second replication and apply being supported in Windows Server 2012 R2, the backup operation is expected to collide with HRL log apply more frequently – resulting in error scenario 1 mentioned above. A robust retry mechanism is needed to ensure a high backup success rate. In case the backup product is unable to retry or cope with failures then an option is to explicitly pause the replication before the backup is scheduled to run.
Update 25-Apr-2014: The DPM-specific details on this post have been moved to the DPM blog.
Hyper-V Replica is one of my favorite features and I love the backup scenario in this article. Just a word of warning with respect to Exchange, which is mentioned in this article as one of the workloads Microsoft tested with internally. At this time the Exchange team does not yet support Hyper-V Replica, so don't use Hyper-V Replica to create a copy of your Exchange servers in production.
"BO-HO" is not a word. And "home office" used in such a context would refer to the user's residential work environment, no the main office. Ref SO-HO.
Jetze: As of today, you are correct :). Hopefully we can do better in the future!
ToffenDask: Nice catch. We tend to refer to HO as "Head Office" (and not "Home Office"), and that captures the intent better. BO-HO refers to a Replica deployment where there are multiple remote sites and one central larger site that connects all of them in a star configuration.
Our experience with trying to backup up replica's using DPM 2012 R2 has been horrible. Approx only 1 in 10 backups work and nearly all servers require daily consistency check, many of which fail.