Welcome to the BackupAssist Blog


Hyper-V Backup Solution

February 9th, 2009 by Linus
facebooktwittergoogle_pluslinkedin

For the last month, we’ve been testing and working on Hyper-V integration with BackupAssist to provide a backup solution for Microsoft Hyper-V platforms.

Today, I’m pleased to announce our strategy, and that we’re due to release our Hyper-V support in our next update, v5.2 – which is due out next week.

Please note: I will follow this blog entry with a full discussion and case study. I started writing it, found it ran to many pages, and decided to keep it brief on this blog. This blog entry refers to backing up the Hyper-V machines from the host, for rapid disaster recovery purposes. I’ll address the question of backing up from within the guest at a later date.

Hyper-V integration with Windows Server Backup

We’ve put in an easy way to select Hyper-V backup from within the BackupAssist console, as shown below:

Select the Hyper-V VSS writer easily

The UI will clearly show what VMs are on your system, and which volumes you’ll need to select to back them up. (But for various good reasons, we won’t force you to back them up.)

Verify which volumes need to be backed up

Recommended backup device

Our recommended backup device for backups of this type (complete system imaging) is eSata hard drive. We easily achieve 150 GB/hr transfer rates on even desktop grade hardware. We only got about half that throughput on USB 2.0, with the same hard drive enclosure.

We also recommend that multiple disks be used for the backup, so they can be swapped onsite and offsite, according to a media rotation strategy. Use the reminder email, media checking and eSata hardware support (safely remove hardware and scan for new hardware) in BackupAssist to ensure that the backups are performed according to plan.

BackupAssist running on Hyper-V Server and Server 2008 with Hyper-V role

BackupAssist can run on both Server 2008 and Hyper-V Server (the free download from the Microsoft website), so you can install BackupAssist on both variants. Be sure to download the correct version of BackupAssist, as the version for Server Core and Hyper-V is much bigger and includes several prerequisites.

Performance testing

We’re part way through performance testing to assess what level of performance degradation that guests machines might experience when a backup is running on the host.

So far, we’ve found that the actual backup duration of successive backups is actually comparable to that of the initial backup, so the speed advantage normally expected from differential imaging doesn’t seem to be there.

However, the highly efficient storage of past versions of backups does perform as expected. On our test machines, we’re backing up just over 140 GB, consisting of Windows Server 2008, plus 6 Hyper-V guests. Each time we run a backup, the overall backup size increases somewhere between 0.5 GB and 1 GB. This clearly demonstrates that the differences are small and that hundreds of days of backup history is possible on each device.

Based on our testing, for the size of the systems we’re simulating, we recommend running the backups no more than 3 times per day. When we conduct more testing, we’ll be able to come up with more thorough guidelines.

Again – we’ll be releasing this updated version of BackupAssist next week, and I hope to publish my performance test results as well around the same time.

facebooktwittergoogle_pluslinkedin

More posts

RSS feed | Trackback URI

2 Comments »

Comment by Jeff Nay
2009-10-22 11:32:45

I am looking for a live backup method that would include backing up a VM hosted on one Hyper-V Server to another Hyper-V Server capable of hosting the VM should a failure occure on the first host, the second host would have a live up to date copy of the VM that could easily be started. This would allow for an simple failover method without clustering.

I would of course also want to keep a historical backups of that VM on external drives.

 
Comment by Brian Collis
2010-09-17 13:26:48

Hi Jeff
Look at putting your VM’s or at least the data vhd on an iSCSI box. When the first server fails and you start the second server, all the data will be current at the time of the 1st server failing. It would also reduce traffic caused by the “live” backup between servers. A neat box I have come across that supports iSCSI, and is not expensive is the Ctera C200. (have not used it in this senario, and it does a lot more than just iSCSI). If you don’t want to use external hardware you could use FRS included with Server 2003/2008. Configure an DFS/FRS share on the two servers. Point your clients to the FRS, they will find the closest/working server publishing the DFS share point. (DFS/FRS replicate file changes between all servers hosting the DFS share)
Hi Jeff
Look at putting your VM’s or at least the data vhd on an iSCSI box. When the first server fails and you start the second server, all the data will be current at the time of the 1st server failing. It would also reduce traffic caused by the “live” backup between servers. A neat box I have come across that supports iSCSI, and is not expensive is the Ctera C200. (have not used it in this scenario, and it does a lot more than just iSCSI). If you don’t want to use external hardware you could use FRS included with Server 2003/2008. Configure an DFS/FRS share on the two servers. Point your clients to the FRS, they will find the closest/working server publishing the DFS share point. (DFS/FRS replicate file changes between all servers hosting the DFS share)

Brian Collis
Computer Net-WORKS Ltd

 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> in your comment.

Trackback responses to this post

Talk about this page:

Follow us on Spiceworks