Senior Product Specialist, Data Protection
Disaster Recovery has been on many people’s minds of late, and the trade press is full of stories. American Express OpenForum has a piece rating the most dangerous cities in America in which to start a new business, based on the risk of a disaster. I found the rankings surprising (New York City is 5th?), but worth a read.
Network World delivers on story on how DR plans are getting more urgent based on an increase in the rate of disasters. They provide this alarming quote:
“Last year was the worst year we’ve had in the history of disasters,” said Al Berman, executive director of the Disaster Recovery Institute, an industry group.
They also note how the widely reported shutdown of the Amazon cloud service put paid to the idea that cloud services were invulnerable (if anybody had that idea in the first place).
Computerworld gets more into the IT side of things with “4 tech trends in IT disaster recovery,” which discusses cloud, virtualization, mobile networking and social networks. I didn’t see that last one coming either, but they make a good case for why social networking is something you need to consider in the context of your DR planning.
Disaster Recovery is a huge subject, especially if you broaden it by adding “Business Continuity” into the mix. Then you’re getting into just about everything: personnel, legal, facilities planning, and transportation, on and on, to say nothing of IT and effective product mixes.
My concern is the IT side of things, and even that is a huge subject for discussion and I wouldn’t attempt to scope it all out in one blog post. Rather I’ll focus on one aspect today and then continue to delve into disaster recovery issues in the weeks ahead.
One area where there exists a significant disconnect is between backup and disaster recovery. Since those terms are flexible, let’s define backup as “making copies of data locally” and disaster recovery as “creating copies of data at an alternate location.” Very often these two processes are separate, using different technologies and products. The most classic formulation is making tapes locally and then trucking them off to an off-site location. The down-sides of this are well understood, and the only real upside is that you are using the same backup software product at all steps of the way.
Because tape is cumbersome, more and more users have moved to some form of electronic data transport, a.k.a. data replication over IP networks. It’s safer (no lost tapes), it’s efficient (no manual shipping), it’s faster. But it’s also often handled separately from your backup process. I could write a half-dozen blog posts on the different replication models, but the point is that if you have one process for backup and something completely different for DR, then you’re not maximizing efficiency in terms of time or money. And if you’re doing array-based replication in a multi-vendor disk environment, you’ll find yourself managing multiple separate replication processes and completely different recovery workflows. It’s a mess!
That’s why with NetApp Syncsort Integrated Backup (NSB) we’ve done some very effective things to make sure DR is a seamless part of the backup environment.
First, we consolidate backups from any primary storage environment onto NetApp disk. Replication is handled by NetApp SnapMirror. This centralizes all your replication onto a single platform no matter what mix of primary storage you have (it even includes data from internal boot disks). Management is simplified and you can reduce costs by eliminating primary storage replication licenses.
Second, there is no additional impact from replication. NSB uses standard backup data on secondary disk as the source data for replication. No additional backup passes, no impact on your applications or primary storage at all. This is far more efficient than doing replication off your primary arrays, for example, or from your ESX servers. Why would you want to impact your production workloads with replication overhead when you don’t have to?
Finally, all DR recovery processes are run from the same NSB console as your regular backups, and the recovery workflows are the same. If you know how to restore locally, you know how to restore at the DR site. This reduces learning curves and management overhead.
Of course there are a lot more details I could get into but this gives you the idea of how NSB can really drive down the cost and complexity of disaster recovery. And it is easier than you’d ever think to test your disaster recovery. I wrote about DR testing here and will be talking more about this in the future.
