Welcome to part two of our blog series, Understanding Backup and Disaster Recovery as a Service. In our previous article on The cost of downtime, we considered how your recovery time objective (RTO) can help you understand which strategy best suits your organization. In this article, we will be going deeper into recovery objectives and how setting the right recovery objectives determines your data security and recovery needs.
Recovery objectives are a measure of your disaster recovery plan. Making a decision on whether to backup data or to replicate business-critical systems, how often to backup, how much downtime you can endure and how much data you can stand to lose is determined by setting your;
- Recovery time objective (RTO); this is the amount of time your business can tolerate being down before you can get your systems up and running again
- Recovery point objective (RTO); this defines how far back your recovery should go. It specifies the amount of data you can tolerate losing before you can recover from your last valid backup.
How to determine your recovery objectives
- Consider your availability needs; have discussions with all your departments and management to determine what data, critical systems, and applications are required to be available.
- Define the downtime for each set of data, systems, and applications. How much downtime can your business endure with the above being unavailable before it begins to have an impact on your business?
- Translate into recovery time and point objectives; for example, if your finance department cannot operate without the Sage application for more than an hour and can only afford to lose 30 minutes of data, this means that your recovery time objective will be set at one hour while your recovery point objective will be set at 30 minutes
- Consider what you can achieve; are the set objectives compatible with your current backup and disaster recovery infrastructure?
Data Backup; Painful recovery objectives
There are two main types of backup practiced by organizations today; local backup and offsite backup. Local backup methods include tape backup, NAS backup, backing up files and images to an external hard or USB drive or even an extra laptop. Offsite backup is a backup that is away from your business premises which includes cloud backup, Google drive or carrying home your local backup devices.
Like we discussed in our previous blog, organizations with data backup only can experience long recovery hours in addition to organization downtime.
Backup scenario 1
You have one or more databases where data from your critical systems and applications is stored. You have set your backup agent to initiate a backup of the previous day’s work every day at 5:00 a.m. It’s Tuesday afternoon and all your systems and applications are running smoothly. At 3:00 pm, your neighboorhood experiences an abrupt power blackout that immediately shuts down all your systems.
This prompts your backup generator. Power is restored and your systems are back up after a few minutes. However, your IT department learns that the abrupt shutdown has led to the corruption of your database. Thankfully, you have a data backup. You do not have to worry about trying to recover the entire corrupted database. You can restore your data up to your last valid backup which occurred that morning at 5:00 am. However, you have lost 10 hours’ worth of data.
Consider your organization, what will be the impact of such a scenario?
Backup scenario 2
You have on-premise systems and applications, some are considered critical, some are not. You have set your backup agent to initiate a backup of the previous day’s work every day at 5:00 am. On Tuesday morning, your IT department learns that at 4:30 am, your organization was hit by a ransomware attack and you cannot access your now encrypted data. Furthermore, the critical system where the ransomed data is stored will have to be formatted in order to become usable once again. The hackers are now demanding a ransom in order to release the decryption key.
Thankfully, you have a data backup. You can recover your data until your last valid backup which was done on Monday morning at 5:00 am. If you choose to not pay the ransom, you will have lost 23 hours and 30 minutes’ worth of data. In addition, restoring your backed up data whether from local or cloud backup, may take up to a day depending on the size of the data. You could be looking at a few days of downtime while you restore your data and rebuild your critical systems.
If you have a local backup such as a NAS device, tape or external hard drive, it cannot help you since you have no infrastructure to restore it to. If you have cloud backup, you can contact your cloud service provider who can begin to download your data onto an external device and deliver it to you. This can take a few hours to a day. Essentially, you will lose an entire day’s worth of business and might be looking at two or three more days of downtime if restoring your critical systems does not go as expected. What will that mean for your organization?
In a worst-case scenario where your critical systems crash due to overheating, high workloads, hardware failure, etc. this means that you will have to do a full replacement of the damaged infrastructure before you can restore your backed-up data. This could mean two or three days of downtime ahead or more. You will recover eventually, but at what cost?
In whatever situation, experiencing downtime is a matter of when not if. Organizations that continue to function with data backup only will continue to suffer painful recovery objectives. In our next blog in the series, Understanding Data Backup and Disaster Recovery as a Service, learn more about how you can eliminate painful recovery objectives with disaster recovery as a service.