What is your disaster recovery plan when your data is in the cloud? Many people think that since their data is in the cloud that it has a built in disaster recovery capability. They can’t be more wrong. Let me give you a few scenarios that have or could happen.
Let’s say you’re hosting in the Amazon Cloud. They have you covered. Oh, wait, didn’t they have a number of huge companies lose data permanently because of some failure in their software?
Not to worry…you’re hosting in Azure. Oh, wait, didn’t Azure go offline with a bug in the software dealing with dates?
No biggie, I’m hosting my own data off site in a cloud system where I provision my own servers and software. Oh, wait, have you ever heard of internet connections being cut, or power loss for long periods of time when a backup generator runs out of fuel? How about earthquakes, tornados, etc. taking systems offline? How about floods, or terrorist activities. How about hackers and people with malicious intent? How about disgruntled employees?
The point is that there are number of risks with greater catastrophic impact than a drive or server being lost. In a real world, you must have the ability to move your database from one system to another with the least amount of data loss reasonable. The probability of failure is low. But, will your business survive if a disaster comes?
So, how do you transport data so that it can be restored elsewhere? Here are some methods that are still popular.
SAN Replication – Two SANS collocated replicate at the binary level so that everything is transported, not just the database. This is really solid technology if you can afford and use SAN storage. Sometimes you can get this from a Cloud provider.
Log Shipping – Transaction logs from your primary instance are transported and restored in an offsite location. This is more difficult to do in Azure unless you are using your own instances of windows and SQL Server. You’ll have to use a different method for Azure SQL.
Backup to Cloud Storage. Azure blob storage is perfect for offsite backups. If you compress the backups it costs little to maintain them in a Blob, and if you can simply save them there in case you need them, which will take a little longer to get back online, then your cost is highly reduced.
Backup to a device and have it transported to a secure, off site, storage facility. This is often a warm failover site where you can have servers brought up for restoration in a matter of hours.
There are many more strategies you can use. It will be worth your time to research this topic if you find yourself in a position where you are responsible for a disaster recovery strategy.
Cheers,
Ben