How to Implement Instant Hyper-V Disaster Recovery
This article explains how to implement a low-cost, almost zero downtime disaster recovery strategy using BackupChain's Hyper-V replication feature.
The Situation: You Need a Hyper-V Disaster Recovery Plan
Say you have a couple of Hyper-V, VMware, or other virtual servers that you want backed up and a spare machine
that could function as your disaster recovery server. This example uses Hyper-V but the process is identical for
VMware, VirtualBox, Virtual PC, and Microsoft Virtual Server as well:
You would usually want the spare machine to remain on hold and if your live server(s) fail you want to power up the VMs on your spare server with minimal downtime.
In addition you want backups so you want to go back in time in case there was a problem that went undetected for while.
Hyper-V Backup and Hyper-V Disaster Recovery Solutions Integrated
BackupChain may be easily configured to implement both strategies:
1. Run a periodic or scheduled backup of your VMs to a network share, SAN, local or external drive, and even FTP/FTPs using deduplication and data compression.
2. Using a second task and schedule, point the backup to your Backup Server, which will function as your disaster recovery server.
In the BackupChain Deduplication and Compression settings, turn off deduplication and compression. By switching off both you achieve a plain file backup which basically replicates your VMs to your other server.
3. On your Backup Server, set up Hyper-V and point the VMs to the replicated folder but leave the VMs off, so that BackupChain can update the VHDs.
Conclusion
By using two servers you can simplify your Hyper-V Disaster Recovery plan and save on software license costs. You can augment your backup strategy with the above strategy to achieve a near zero downtime at a fraction of the cost of cluster shared volume solution or other shared storage solution.
A nice bonus of this combined disaster recovery strategy is you do have several backups and you can restore older versions of your VM if necessary. More often than not, data loss isn't realized until quite some time after the damage took place. Having a backup history allows you to go back in time to restore previous VM versions or to recover files deleted in the past.
You could share a single Backup Server for several live servers since the Backup Server sits idle most of the time. It doesn't need to offer the same hardware performance as your production servers. In case of a disaster it will probably only take over the load for a short time while you are rebuilding your production server. In addition, it's rare for multiple production servers to fail simultaneous (however it does happen, imagine flood, storm, or fire damage!). Depending on your situation, a single Backup Server may suffice and may be able to take on the VMs of a damaged production server for a short time. Try our Hyper-V backup solution for 20 days using our trial version.
Contact support (or call your Priority Support number) for further assistance.