Backing Up Hyper-V Replica Virtual Machines In The DR Site

I’ve spent much of the last 6 weeks either thinking about or working on Hyper-V Replica. The topic of where to do backups came up in conversation. Normally it is advised to do a backup in the primary site and replicate the data offsite, ideally to the DR site where it will be readily accessible – storing it in an offsite warehouse that it under the same 3 metres of water as the production site is pretty useless!

Before you ask: Replication is not backup. Replication gives you current/recent copies of VMs/data.  Backup gives you an archive of days, weeks, months, or even years. And your need to retain archive data doesn’t disappear (practically or legally) just because you have invoked your DR plan.

So in the conversations, one of the guys wondered if maybe it would be more efficient to do the backup in the DR site.  That would mean running backups of the replica virtual machines that are created and maintained by Hyper-V Replica.  An interesting concept!

Patrick Lownds (Virtual Machine MVP, and co-author) quickly responded with a “no” thanks to a post that appeared on the TechNet blogs last night:

Backing up or restoring the Hyper-V replica is not supported.

Due to the inner workings of the Hyper-V replication architecture which may be in progress during the time of a DPM backup, there can be no guarantees of a successful backup or restore of virtual machines that reside on the Hyper-V Replica server.

My guess is that the HRL replay which is updating the replica VHDs every 5 minutes would prevent a reliable backup in the DR site.

That means that you should (and can) continue to backup the source virtual machines in the production site, and continue to replicate your backup offsite to the DR site.

For the wise-asses out there (you know who you are), let’s be clear:

  • Yes, you can still use Hyper-V Replica
  • Yes, you can continue to backup replicating VMs in the production site
  • Yes, your backup tool might be able to backup replica VMs in the DR site, but that doesn’t mean that this is supported. Don’t come crying to me (or anyone else) if you ignore this statement and your “engineering” bites you in the ass.
  • Non-replica VMs that are running on the DR site hosts can be backed up in a supported manner
Technorati Tags: ,,

8 thoughts on “Backing Up Hyper-V Replica Virtual Machines In The DR Site”

  1. What about useing Start-VMFailover -AsTest in a pre-backup script? As you get a copy of the VM with a differencing VHD, that is save to start and test, it should be save to back up, too.

    A supported way to back up the replica would be great for those (me) running Hyper-V in smaller remote offices as well as central, bigger sites housing the backup hardware.

    It’s a shame that the referenced TechNet blog is so light on details, but a general “not supported” ends the discussion for now, I guess.

    1. Hi Mirko,
      Nice idea, but the problem is that the test failover VM is only using a differencing disk. That means that the only stuff you’d get consistently would be the changes from the replica VM with it’s original VHDs and AVHDs (if using historical copies features). Those original (A)VHDs would continue to be updated by HVR and therefore backup would still be unsupported.
      Aidan.

  2. What about using 2012 R2 Hyper-V to make your replication cycle longer – or temporarily stopping replication while backup jobs are scheduled? The backup job just needs enough time to grab a VSS snap – which is probably about a few minutes…right?

  3. I’ve been trying to get backups working against a hyper-v replica site (tried Arcerve UDP [great product BTW], and MS DPM). Sometimes the VM’s at the DR site backup but usually they get stuck “Backing up” and during this time the replication is failing. And the only way to recover is to restart the Hyper-v VMMS service, then resume replication from the clients. Some clients also end up needed to be re-synced.

    It’s a shame because if MS could get this to work, this would prevent us from using double the bandwidth to offsite our backups. Currently we HVR all VM’s to the DR site, additionally, we Arcserve UDP (which uses dedup tech so it’s not as much bw but still uses some especially during initial seed) the same VM’s offsite to the same DR site over the same WAN link. So we’re wasting bw. If MS could solve this it would be great.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.