Support for protecting replica virtual machines
Updated: May 13, 2016
You can back up replica virtual machines on a secondary server if DPM is running Windows Server 2012 R2. This is useful in a couple of scenarios:
Reduce backup impact on running workload—Taking a backup of a virtual machine incurs some overhead as a snapshot is created. By offloading the backup process to a secondary remote site, the running workload is no longer impacted by the backup operation. Obviously this is applicable only to deployments where the backup copy is stored on a remote site. For example, you might take daily backups and store data locally to ensure quick restore times, but take monthly or quarterly backups from replica virtual machines stored remotely for long-term retention.
Limited bandwidth—In a typical remote branch office/headquarters deployment you’ll need an appropriate amount of bandwidth is provisioned by administrators to transfer backup data between sites. If you deploy some type of replication and failover strategy in addition to your data backup strategy, you might be sending copies of the same data over the network. By backing up the replica virtual machine data rather than the primary you’ll save the overhead of sending that backed up data over the network.
Hoster scenario—Customers might use a datacenter hosted by a hoster as a replica site, with no secondary datacenter of their own. In this case the hoster SLA will require consistent backup of replica virtual machines.
Data consistency
There are two broad types of data consistency for backed up data:
Application-consistent backup—Takes a backup of applications running on a virtual machine in a consistent state, as would happen if the application were closed normally. For DPM uses application VSS writers to take a snapshot of an application in a consistent state.
Crash-consistent backup—Takes a snapshot of consistent data but doesn’t capture memory contents or pending I/O operations.
A replica virtual machine always turned off until a failover is initiated, and VSS can’t guarantee an application-consistent backup for a replica virtual machine. Thus backup of a replica virtual machine will be crash-consistent only. If crash-consistency can’t be guaranteed then the backup will fail. This can occur in a number of conditions:
The replica virtual machine isn’t healthy. It’s in a critical state.
The replica virtual machine is resynchronizing (Resynchronization in Progress) or in the Resynchronization Required state.
Initial replication between the primary and secondary site is in progress or pending for the virtual machine.
.hrl logs are being applied to the replica virtual machine, or a previous action to apply the .hrl logs on the virtual disk failed, or was cancelled or interrupted.
Migration or failover of the replica virtual machine is in progress.