Virtual recovery

The rise of the virtual machine has opened up an interesting new set of methods for doing backup/failover in the event of a disaster. Clearly, it’s much faster to start a VM on a server than it is to reinstall that server from tape or even from hard disk. The question is: “Where do you want to restore to?” Since you can freeze-dry a server and unfreeze it within seconds, there’s a whole new range of possibilities available for you to think about for maintaining business continuity.

Virtual recovery

Here’s one that we’ve been pondering for a client recently. Before I start, let’s be quite clear that this isn’t a solution that’s going to work well on the end of a slow ADSL connection, especially one that comes with any sort of “fair use” clause in its contract. To even consider this solution you need to have a strong relationship with your connectivity supplier, and your feed should effectively be a 1:1 connection with zero contention. If you’re a bigger outfit you might well have multiple providers on multiple gateways, of course, especially if you’re a multisite corporation that uses VPN tunnelling. But many smaller businesses are single site and like to run their servers locally: their ISP probably provides email filtering for mail coming into the site, and backup for SMTP mail in the event of a line failure.

So what options are available to a business when the line fails between them and their ISP? This is a topic we’ve been chewing over with my line supplier, merula.net, which has a shiny new datacenter in Huntingdon. I have a server in the racks there that I use for my external facing needs, and it works very well indeed – the connectivity is excellent, and I can download a few gigabytes of OS build from Microsoft or Apple in a matter of a few minutes. The slowness lies in the connection speed between Merula and myself, even though I have a pair of ADSL Max lines running in parallel, bonded together by the wizardry of a new Cisco router.

If I were running an e-shop then I’d need to decide whether to run it from the Huntingdon rack or whether to host it locally. There are some advantages to hosting locally: it would be closer to my database servers, so I’d be able to keep up to date with my stock control more easily (at least that’s the theory, although many major e-shops prefer simply to lie about their stock levels). I could also make quick adjustments without the inconvenience of fettling a server at arm’s length, although I have to say that any changes that aren’t properly tested should never be applied to a live shop anyway, whether it’s local or remote! Again, such caution flies in the face of industry so-called “best practice”.

No, my real worry is line failure. I need to keep the shop running, which means something has to be running in Huntingdon in that rack. So what are my options? I could use the interesting new technologies in SQL Server and Exchange Server 2008 that let me do “log shipping”, which batches up the database transaction logs and sends them to a remote database where they’re played into the server. This ensures that the two databases, one remote and one local, are actually in sync for the time window it takes for the log ship to take place.

If the line went down I could get Merula to switch my routing to the rack-mounted servers and keep on working, or it could even set up some sort of routing failover for me. This sounds good, but might require a lot of thinking, planning and testing. How about a slightly more brute-force approach? I can perform a freeze-dry of the e-shop state at 3am, so why not just send this VM image up to Merula every night? The company can ignore it most of the time, until we actually hit a real problem when it can just instantiate enough of my network “remotely” to keep the outside world happy.

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.

Todays Highlights
How to See Google Search History
how to download photos from google photos