Best Part of Hyper-V Backup and Recovery Is Windows!

I speak with lots of customers about virtualization every week.  I’m always interested in how they manage their virtual environment, and often dig into their operational procedures and practices.  I find that organizations who adopted virtualization earlier have not taken full advantage of the technology.  Backup and recovery is a great example of this. 

How do you backup and recover your virtualized servers?  Do you still leverage agents inside the VMs to a central backup infrastructure?  Lots of companies charged down the “virtualize to consolidate” path without altering their backup and recover processes.  Savings realized through server consolidation can be substantial, but by not updating their backup method, they miss out.  In the event a server (VM) needs to be restored for some reasons,  leveraging an agent-in-the-VM backup means the server (VM) must be rebuilt and then restored.

Why not take advantage of the encapsulation of server instances to improve disaster recovery?  VMs live in files, why not backup and restore the few number of files that represent a VM, rather than reconstruct all the files and settings contained in those files?

VMware offers VMware Consolidated Backup to backup a VMware host and the hosted / encapsulated virtual machines, but it is by no means a low cost backup solution.  It still requires a VMware 3rd party backup solution as well as the extra cost of  VMware’s tools (at least VI Foundation).  Even with all that, it’s not a simple process to get it working.  I know that some people believe that Microsoft licensing could be simpler, but personally I think VMware makes things as simple as licensing backup capabilities hard with statements like, “To leverage the new Consolidated Backup capabilities — and backup of all virtual machines running on an ESX Server host — a VCB license key must be available for each processor within that host. Refer to the Virtual Machine Backup Guide for a description of this feature." Leave me a comment if I’m off base about the cost and complexity of VMware Consolidated backup.

Enough about all the added cost and complexity of VMware…the important question is…did you know that everything you need to do a Hyper-V backup is included in Windows Server?  Did you know that there are at least two ways to make complete, consistent backups of VMs on Hyper-V that can be quickly and easily restored?  Over the coming weeks, I want to show you how to backup and recover Hyper-V VMs using the “stuff” that comes in the box with Windows Server 2008 R2 (and then talk about System Center Data Protection Manager and why you might want to check it out too).  I’ll break my posts into four areas:

  • The Wonder of Volume Shadow Copy

  • Backing Up Non-Windows – Wicked Coolness

  • Using Windows Server Backup (WSB) for Hyper-V

  • DiskShadow / Xcopy backup of Hyper-V

  • System Center Data Protection Manager with Hyper-V

  • Cool 3rd party tools for backup and recovery of Hyper-V

Be sure to stay “tuned in” to learn how to efficiently backup and recover Hyper-V.


Comments (5)
  1. JohnKelbley says:

    I certainly will talk about that in later posts – I want to get to the basics first, though.  

    Backup and recovery for CSV-based VMs is still evolving.  BTW, NetApp just released an interesting tool that supports CSV:


  2. troth says:

    make sure to cover vhd residing on csv based volumes!

  3. JohnKelbley says:

    Tony – let me know what issue you are having, I’m very interested!  Send me an e-mail with details if you want… my e-mail is john kel @ <youknow>.com  

    take out the spaces and put the company name and you should be all set.


  4. tonyr says:

    yep have netapp onsite working the details now! Seems there are some problems with vss etc..

  5. tony roth says:

    sorry been away,  the issues were not related to anything to do with either ms or netapp, snapmanger depends on a working infra structure things like dns etc. We had RPC issues that snapmanager seems to depend on to communicate with the vss writer. The filer was sitting in another domain with a poorly maintained dns systems. It did not have proper forwards and reverses configured. Thus the vss writer request would fail!

Comments are closed.

Skip to main content