Disaster Recovery FAQ: Answers from Our Experts
Disaster recovery is a vital part of any backup strategy, but sometimes it's not clear how it differs from your everyday backups. A Microsoft survey discovered most organizations experience 4 or more disruptions each year with an average cost of $1.5 million an hour. To fight the high cost of downtime, 43% of IT professionals are planning to invest in or improve their business continuity with cloud-based disaster recovery, citing reduced costs and expanded coverage as their primary reasons.
With disaster recovery (DR) taking such a high priority in the IT world right now, we asked our resident expert David Dotan Sofer, CTO, to answer some of the most common DR questions.
HOW IS DR DIFFERENT FROM A REGULAR BACKUP?
Backup is a traditional model that I think most people are familiar with. It’s when you have a tape drive or attached storage in your server room and you’re performing a backup on a weekly or maybe a full plus schedule. So you’re getting an archive of your data, with all these retention points, so you have daily, monthly, weekly, maybe yearly copies of your data.
Disaster recovery gives you a smaller range of recovery points – usually going back just hours – but it’ll allow you to recover a larger range of that data, whether it’s an entire datastore from your SAN or an entire server, and you can recover that to a separate facility. You can do this very quickly, too.In most environments, we recommend people have both a backup and a DR solution.
I’VE HEARD ABOUT RPO AND RTO. WHAT DO THESE MEAN FOR MY DR STRATEGY?
These two things are two of the most important when putting together a DR solution. RTO is recovery time objective, or how quickly you need your infrastructure to be ready again in a new location. For instance, this is my critical ERP system so I need that to be back up within an hour. Or, I don’t need my payroll system until the end of the pay period, so I can afford to leave that down for a few days.
Recovery Point Objective is how much data can be lost between the source and the target within that replication. That’s usually the length of time it takes for the data to get from the source to the target. So if it’s a website, and you don’t push regular changes to your site, you might have a higher RPO. But if it’s a highly transactional database, you want to have a really low RPO, so as much of the data as possible will be replicated on to the target environment.