Updated on November 8, 2019 by Rick Emlet
According to one recent study, approximately 140,000 hard drives fail in the United States every single week. Even the cost of a modest drive recovery process can be significant … and success is never guaranteed. If you really needed another reason to understand why data backups are so important for small businesses in particular, let it be those two statistics.
But at the same time, all of this begs the question – just how often should your business be backing up its essential data, anyway? Isn’t ALL data essential? You can’t really be expected to back things up every second of every day, can you? The reality is that not all applications and the associated data are equally important to running a business. Each application/data should be prioritized by the business teams into categories (critical, high, med, low) with each having its own RPO/RTO values. Once that is completed the IT department or your CSP can design a solution that meets the different requirements. Of course, disaster recovery is much more than IT folks doing IT stuff. Enterprises must also have a plan for personnel, facilities, access, etc…all of which is beyond the scope of this article which focuses on the IT component of disaster recovery.
Thankfully, developing a backup and disaster recovery strategy – complete with the right backup frequencies to keep you protected – isn’t necessarily as difficult as you may have thought it would be. It IS a very specific process, however, and one that requires you to keep a number of key things in mind.
RTO and RPO: What They Are and Why They Matter
To get a better understanding of just how often a business should be backing up its critical data, you must first become more familiar with two concepts that strike right to the heart of your backup and disaster recovery strategy.
RTO and RPO are acronyms that are short for “Recovery Time Objective” and “Recovery Point Objective,” respectively. Keep in mind that in a perfect world, you’d be backing up data often enough (and your strategy would be designed in a way) that lets you immediately pick right back up again after a disaster like nothing ever happened. You’d have your systems fully restored as quickly as possible and it would almost be like nothing ever happened.
RTO and RPO are big, big parts of how you get to that point.
Your Recovery Time Objective refers to the total amount of time that an application or a critical system can be down without causing some level of significant damage to your business. Meaning, of course, that this is the minimum amount of time that can go by before you start to accrue unacceptable costs due to downtime, lost productivity or similar issues of that nature.
Recovery Point Objective, on the other hand, directly relates to your company’s overall data loss tolerance. To put it another way, this is the maximum amount of data that you can realistically lose before significant harm occurs.
The key thing to understand about both of these concepts is that there is no “one right magic number” that you’re trying to hit. Every business is unique unto itself so in order to effectively set your RTO and RPO metrics, you need to look inward and determine exactly what you can stand to lose before you reach the “point of no return.”
So how do these two concepts tie back into frequency of backing up your business data? If your company backs up all of its data to a secure, off-site location every night after employees have gone home and in strictly regimented 24-hour increments, in theory the most you will ever lose is 24-hours worth of data. Depending on your business, this may be perfectly acceptable and at that point, your RPO would be approximately 24-hours.
For other businesses, on the other hand, even losing 24 hours of data would be absolutely devastating. Say you’ve looked at your own internal metrics and have decided that you really can’t afford to lose more than four hours’ worth of data at any given time. In that case, your RPO would be four hours – and that’s precisely how frequently you should be backing up your systems, too. It comes down to a cost-benefit analysis, ie, is your business willing to allocate sufficient resources to meet the RPO objectives defined by your organization? The good news is that back-up and disaster recovery solutions are much more affordable than you think.
The same is true of your Recovery Time Objective but from a slightly different perspective. Keep in mind that every minute your systems are down after a disaster is a minute that work isn’t getting done. It’s a minute where no forward progress is being made and, ultimately, that you’re losing money. Because of that, it would be a mistake to look at RTO as “only” the amount of time it will take between data loss and data recovery.
Think about everything that goes into the “recovery” side of the equation in the first place. Not only do you need to assess the damage of the disaster in question and mitigate risk wherever possible, but your IT people (or your IT support partner) will also need to restore your on-premise environment to proper working order. This isn’t as simple as flipping a light switch. These things take time.
To properly understand your RTO, you need to go analyze your infrastructure and categorize assets like applications by A) priority, and B) potential business loss. Once these points are defined, , you can allocate your internal and external resources accordingly.
If your entire place of business were to burn to the ground one day and take your entire system offline, getting everything back up and running becomes a matter of using your time wisely. You know that Applications A, B and C aren’t really “critical” – which means that you don’t need to spend time immediately worrying about them during a situation where every second counts. Applications X, Y and Z ARE critical, however – meaning that they need to be prioritized in the immediate aftermath of this event.
In a larger sense, it’s important to think about these two concepts like this. Recovery Time Objective is most concerned with your applications and systems. Yes, data recovery is a big part of this – but what this metric is really concerned with are the time limitations that you can sustain during application downtime before things start to get really, really bad. Recovery Point Objective, on the other hand, is focused on the total amount of data you can conceivably lose before your business is negatively impacted in a way that it might never recover from.
Therefore, these two related-yet-different concepts are very much two sides of the same coin. They’re the metrics at the heart of your backup and disaster recovery plans and, once you’ve taken the time to define the appropriate parameters for your business, you will have a roadmap to exactly how often you should be backing up your data.
In the best of all worlds, real time replication to a hotsite is the ideal solution where all data stored at the primary site is immediately replicated and backed up at the disaster recovery site. Obviously, you should be backing up critical information as often as humanly possible because you never know when disaster might strike. But for all organizations, that isn’t always economically feasible – which is why RTO and RPO are two critical metrics which your business needs to define, understand and implement. Start here when building your backup and disaster recovery strategy and, at the very least, you’ll know that you’ve done everything you could to remain as protected as possible given the circumstances.
If you’d like to find out more about disaster recovery and back up solutions that fit your RPO/RTO requirements – the experts at Outer Edge are here to help. Give us a call at 1-844-OET-EDGE or email info@OuterEdge.biz to schedule a meeting.
Related article: Steps to Identify Critical Data for Your Business.
