If you’re not sure how to explain the difference between “data backup” and “disaster recovery,” you’re not alone.
The terms data backup and Disaster Recovery (DR) are often misused when it comes to discussing the protection of a business’ data and IT systems. But as security breaches, natural disasters, and other unexpected events become more commonplace, it’s more important than ever before to understand the true difference between the two, and how they can work together to create a robust disaster recovery strategy.
We break down each—and why they’re both vital to your overall business resilience and continuity plans.
What is Data Backup?
Data backup means a copy of your data is replicated to another device or location, making it recoverable in case the unexpected strikes. Tape drives, offsite backup, and even USB devices can serve as a secondary home for your data. This gives you a means to effectively recover your data in the event of a disaster, corruption, or human error.
And while data backup is important to the overall continuity of your business, this traditional method of backing up your data comes with challenges: Even with your data stored on another device or location, it’s vital your backup solution provides the ability for you to recover all your files, software, and functionality quickly, easily, and without corruption.
For example, if your server died, you wouldn’t be able to quickly get back to work if you only had file-level backup. To start working again, your server would need to be replaced, all software re-installed, all data re-installed, and then the whole system would need to be re-configured with your settings and preferences. This process could take hours or even days—and that’s if you have a clean copy, uncorrupted version of your data safely stored in the first place.
What is Disaster Recovery (DR)?
DR is about making a working copy of the entire production system. The DevOps solution is often termed Blue Green, and would be two identical working production systems hosted in different data centers—the switch between the two being the DNS route table. Under normal circumstances, www.example.com goes to 188.8.131.52, but if something goes wrong, you can automate your monitoring system to redirect your website to 321.321.321.321 and within a few seconds, you are back online. There is a cost here, of course, as you are running two full production systems. However, in the AWS cloud, for example, you could scale the DR version down as it wouldn't be in operation.
There are variations on this model of DR, where a byte by byte copy of the production system is made in real time, to a server in a separate data-center. This is usually a few seconds behind the live version and the switch doesn't involve the DNS. Here, it's done via the DR application. This is better for big enterprise applications, which are not as cloud-friendly, but can be just as expensive to run.
Why You Need a Backup and Disaster Recovery
At Velocity, we run a combination of DR and cloud data backup. We make sure your infrastructure is duplicated so you can switch data centers in seconds.
Then, we take it a step further. We use availability zones, so if a part of the network fails, your data automatically travels to an alternative location within a related data center. We also snapshot all your infrastructure daily, so you can swap one server for the one you used yesterday. This is where the drives are copied, byte for byte, and that image is stored in a separate directory. We only do it at fixed times; it could be once an hour or once a day, depending on circumstances. It takes a few minutes to recover a backup snapshot, and you can't choose that the backup caught every single data byte of your production, due to the snapshot process having to freeze what is happening for a fraction of a second.
Snapshots are the images of your drives, which means they can get pretty big. The more you do, the more storage space you need, and storage costs money. However, the cost is based on how quickly you want to get to the data. If you want it in milliseconds, it needs to be on a mounted drive. If you want it in a few minutes, we place it in a cloud directory. If you want it in a few hours, we place it in an archive. This means you would only delete data for legal reasons rather than to save costs. The reason for this is the further it gets from live, the more processing we can do to reduce the size of files, and place it on different media which is robust for data retention, but not fast to process.
Commons Misunderstandings of DR vs. Backup
What can go wrong? One of the unusual problems we have is customers looking at DR as being a safe place to do unique or unusual testing in production. This often comes down to a misunderstanding of DR, where it’s seen as a spare production rather than its own solution. Another misunderstanding is that DR doesn't save data as its main benefit. This is a fix for a broken production system. If this was in the physical world, it's like carrying a spare umbrella while using your usual umbrella in the rain.
The issues with backup are similar. Customers misunderstand that a restore isn't something to do because of a minor configuration error. It isn't a way to bypass the need for documentation. If you have a configuration error, the better way to fix it is through log analysis, where you check what changed, and reverse that process.
There’s a Better Way for Disaster Recovery
Within Velocity, we do restorations on a daily basis, so we know that the managed disaster recovery process we use works well. There is also the secondary backup process, where we will run backups dedicated for single applications and databases. This means we can leave the server with its current config, and restore only one of the applications on the server. The benefit being that we don't need to make unnecessary changes in the event of a roll back.
Are you interested in learning more about building a DR solution for your business? Contact us to speak to a cloud services.