Can anyone give me any ideas/links so that I can better get an idea of how virtualisation can help me from a disaster recovery point of view?

We have a server sitting in a datacentre, it basically has a has a bunch of web services that sit on the internet and a big SQL Server database.

I'm not looking for anything massively detailed, just something to give me an idea of what's possible.

Many thanks


There are all manner of product-specific answers to this question but the most basic and easy explanation is that a physical server's identity/code/data/etc. are all kept on the disks plugged into the server itself whilst a virtual server's disks are actually just a big flat file on a disk.

And if you can put this flat file onto a shared disk system and then replicate that file to another shared disk system at a second site then you have an identical copy of everything that makes up that virtual server but somewhere else, somewhere it can be restarted and carry on as though nothing has happened.

As I say there's lots of specific products to automate this or make it easier but essentially it's easier because your servers are just files - does that help? come back if you have any more questions.

  • Thanks for the feedback it's very useful to get an idea of what can be done. Do you think there would be any performance issues running as a virtual server? – Geoff Wray Mar 5 '10 at 10:58
  • well yes, there's usually a 5-10% virtualisation overhead (more for IO intensive VMs such as DBs usually) but often people virtualise onto newer hardware so usually see and increase in performance over their older servers - but yes, on a like for like basis it'll be slightly slower. – Chopper3 Mar 5 '10 at 11:12

Here's an example: Our company web sites are hosted externally. As a result of issues with our previous host, which resulted in several days of down time, I now keep a replica of those sites on two machines. One is used for development and testing, so can at times vary from the live site a bit. The other is maintained as an exact replica. This second one is normally only powered up as required for re-replication.

In the event of issues with the web host the machine with the exact replica can be powered up and brought online via a change to the DNS record. As we are a small company there's no way I could justify the expense of an extra server to cover the pretty small chance of it ever being required. Instead I use a virtual machine. It's not as powerful as I'd like but it is perfectly workable.


I've been researching this for my organization, so I think I can give some good insight.

One of the biggest advantages of virtualization is that the virtual machines are hardware agnostic - any hardware capable of running your chosen VM software (VMware, Hyper-V, etc.) can run the virtual machines.

Since the virtual machine is always presented with the same hardware, if your server fails, you can replace it with different hardware and not have to worry about driver issues on the virtual machine, or even having to reinstall the OS from scratch because the hardware is too different. This is especially true for any windows OS, which tends to have more problems changing hardware in my experience.

Another advantage is that recovering the system is just a matter of copying the virtual machine's files over to a new system and starting it. It's usually simpler and faster than restoring from regular backups.

In looking at a disaster recovery plan, you really need to be specific about what kind of disasters you are anticipating, and how much data loss is acceptable. For example, are you planning for:

  • Your server failing?
  • The datacenter failing or losing its network connectivity?
  • The entire building or city being destroyed or inaccessible? (ie. natural disasters)

Virtualization on it's own doesn't solve any of these. What it does do is make solving them easier, and make recovering take less time, and give you more options as to where you can restore your systems.

Another thing that might be an advantage to you is simply the ability to run multiple operating systems on one physical server. In your case, you could seperate your SQL server from the web servers into their own OS. By doing that, if there were problems with the operating system, you'd only have to repair or restore from backups that service, not the entire system. If would also mean that if you outgrow your current server, you can expand by just moving the SQL server to another physical system without having to chance anything else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy