24 September 2013 — 4 min read
Infographic: Disaster Recovery by the Numbers
Disaster recovery, or IT Business Continuity as we like to think of it, is a space that’s riddled with traps. Or at best, it suffers from a number of myths and tendencies toward “fingers crossed.” It’s not just about a fundamental difference between backup and disaster recovery; the idea that it’s one thing to have your data duplicated into a repository somewhere but quite another to be able to actually restore it — also downed applications and network configurations — rapidly…
Example 1: If You Can’t Test it, You Don’t Know it Works
One can’t get serious about DR unless one acknowledges not just the criticality of testing, but also how it applies to a couple very distinct requirement areas:
Firstly, automation. At nScaled for security reasons our internal team doesn’t have log-in rights to client domains and servers. Our platform, however, automates IP address reservation and assignment for remote recovery servers on multiple VLANs. Once servers have been assigned to VLANs in the cloud, our platform offers full test spin-up automation. Users can activate systems in a parallel fashion to perform performance and functional DR tests. After tests are over, the nScaled DR platform will deactivate all systems running in a test mode at user’s request or automatically and all accrued data will be discarded. Our customers are not only testing their DR readiness, but also using our platform to test upcoming updates and patches. Additionally our platform is used as a part of internal development cycle to test apps on a full copy of production data.
Secondly, isolation: A DR system needs to support testing without bringing interruption to primary production environment. We’ve designed our platform to achieve just that. Users can define levels of isolations and apply them immediately. Now, without impacting your business continuity, applications like Exchange, DMS, database servers and others can be activated without worries that those apps will conflict with their production counterparts.
Example 2: Disasters Actually Happen Every Day
Consider something more organic: When most of us think of disasters, we think immediately of big, often natural events. Hurricanes, earthquakes. Big explosions and what not. The reality however, is less dramatic on the surface but actually scarier: In the IT world, disasters technically happen much more often than most people know. They’re also not necessarily singular events as much as they’re domino effects.
It might start with a malfunction in a given system, which after an hour or two of investigation turns out to be a failing board which happens to be a model that’s been discontinued by the original manufacturer. Add another hour or two to find a supplier who actually has a replacement unit or three in stock. Add 24 hours for it to be rushed overnight to the problem site. And meanwhile, service after service starts to fail. The Helpdesk starts clogging with tickets even after IT’s sent out an All-Hands Advisory. They know what problems people are having already without even having to read them, but they open up and respond to them anyway out of courtesy, while they wait for the package to arrive ASAP. And maybe it’s a welcome distraction from considering about how much of the company’s cash and productivity might be getting lost while it’s in transit.
This kind of thing happens all the time. Many of us have become conditioned to accept sudden, frustrating hits of downtime, as an unfortunate but normal cost of doing business. At the time, maybe only a few people treat them as disasters, but then maybe weeks or months later their full impact becomes painfully clear.
It doesn’t have to be that way anymore. With a platform like ours, in scenarios like the once I just described the client could choose freely: Either fail over into the cloud and then back again upon getting the replacement hardware, or simply ditch the hardware and take the opportunity to virtualize into the cloud. With the latter, we’ve even heard from some clients that when moved into our cloud, their systems start to run even faster…
Digesting a Few Key Trends and Findings
Partnered with NetApp (whose customers are leveraging our platform for enhanced recoverability while still keeping all their familiar tools; SnapMirror™, SnapCreator™ etc.), we’re happy to present “Disaster Recovery by the Numbers,” a simple infographic that condenses a few key facts about Disaster Recovery for quick, easy review. A few of its metrics, particularly once visualized in juxtaposition, frankly took even some of us aback.
For the full version, just click the thumbnail to the left. We look forward to your thoughts.
Want to get in on our other, ongoing research efforts?
Be sure to also check out our IT Business Continuity Survey for 2013.
