If you think about the contents of a Disaster Recovery Plan, you will quickly come to realize that all persistence requires a plan. It doesn’t matter if it is NoSql, files, a Self Managed SQL Instance, or even a cloud hosted platform such as SQL Azure. Let’s take a quick review of some of the components of a Disaster Recovery Plan.
Backups
Backups (of any type or strategy) are required in a Disaster Recovery Plan. Without backups you could lose all of a companies valued data resource that sets them apart from other competitors.
Restoration
A Disaster Recovery Plan has a number of data (and application) restoration strategies, depending on the environments and services in use. The reality is that ANY host can die. Jet planes can fly into your data center. Earth Quakes can break your fiber optic internet connections. Power outages can shut you down. These are generally catastrophic issues…but they happen. Do you have a plan for when they do?
Some systems have more redundancy built in, and by nature of deployment already have failover capabilities. SQL Azure is a great example. It has redundant instances of your database. The online database is mirrored to a failover database, which is also mirrored by another failover database. If one goes down, another instance is spun up to make it near impossible to experience data loss.
Replication of data is common for all kinds of database storage engines. Some of the most powerful failover is performed using SAN replication.
Plan Execution
Regardless of your failover strategy, you have to test it to know that it will work if a disaster strikes. I’ve been a participant in a number of failover tests. Only about 50% succeeded fully. A failover test must be able to replace any part of your production environment that you can’t lose, including application code and servers. In short, you need to be able to create a complete mirror system, and be able to perform your core business processes without any dependency on an outside production system.
Summary
That being said, it makes sense to me that a Disaster Recovery Plan is required regardless of your implementation and failover strategy. You may never use it for anything other than a test. It’s like having automobile insurance. You really don’t want to use it. But, it is important to know that it is there, and that your coverage is adequate.
For those of you running SQL Azure, thinking that’s all the Disaster Recovery necessary, please give me a call the first time some bone head corrupts your data, and you can’t roll back to a previous point in time.
Cheers,
Ben