In business, having contingencies for potential problems tends to be advantageous for the business that wants to stave off ruin. When you are dealing with information technology--specifically data--ensuring that it is protected against loss in the face of the litany of threats out there is an undertaking in itself. A disaster recovery strategy is created to govern the processes a business develops to recover to restore operations in a manner that will keep the business in business. This month we take a look at two of the core variables of a disaster recovery strategy: RPO and RTO.
A recovery point objective is measured in time. The figure describes and determines how much data a business is willing to lose in the event a disaster strikes their business. This metric is a good one for an organization to determine how often to perform data backups, since in theory, the more data you need to maintain, the more frequently you will be backing up said data.
A recovery time objective is also measured in time. It determines how much time you can go without recovering data and IT infrastructure before you lose continuity of your business. After a disaster it is extremely important to get data and infrastructure back up as soon as possible, but some businesses can function better than others without access to its normal critical data and infrastructure.
RPO and RTO are both metrics widely used in business disaster recovery and need to be qualified properly in order to be effective. To help you and your network administrator set up a disaster recovery platform that is right for your business, we look at some of the differences between RPO and RTO:
This is where it gets tricky. You would think that RPO is easier to calculate because there are fewer moving parts, right? The problem is that you can only restore data to working hardware, and if a disaster knocks out your organization’s server, for instance, you won’t be able to restore anything until new hardware is procured. So when calculating an RPO, you have no choice but to do it by calculating inherent cost and demand for data. RTO, on the other hand, has to stay aligned with what is possible. If your business’ RTO is too close to its necessary RPO, you business may be in jeopardy if a major outage such as a server failure takes place.
The costs associated with maintaining a strict RTO will likely be greater than those for RPO. This is largely because in the case of RTO, you are looking at the complete computing infrastructure, while RPO is just about data. As far as the assessment of each, RTO incorporates a lot of your business’ more crucial needs, while, again, RPO is focused on data.
To meet your organizational RPO goals, all you need to do is perform data backups at the interval specified by your RPO assessment. Since data backup is one of the easiest parts of your business to automate, having a strong RPO strategy is simple. Unfortunately, there is no practicable way to automate RTO, since many of the systems that need to be restored are likely physical hardware systems.
When building a disaster recovery plan that will keep you in the game after a disaster, but also won’t cost your business a lot of capital, setting realistic RPO and RTO goals is critical. For more information about RPO and RTO, or disaster recovery, reach out to our knowledgeable professionals today at 586 258-0650 .
Comments