Alexa metrics
Live Chat

Welcome to UKFast, do you have a question? Our hosting experts have the answers.

Chat Now
Sarah UKFast | Account Manager

Choosing the Right Data Protection Routine

19 March 2010 by The Brigadier

How do you choose the right data protection routine?

The impact of data loss or unavailability is an area of concern to any business that associates any level of importance to their online presence. The level of concern is determined by the available budget and also the costs associated with data either being permanently lost or data just being unavailable for any period of time.

Data (all or part) being permanently “lost” is commonly known as the “Recovery Point Objective” (RPO) – the more precise definition being “the amount of data loss, expressed by an amount of time, which is acceptable”. The agreed RPO will determine the type and frequency of data backup.

Data being unavailable for any period is commonly known as the “Recovery Time Objective” (RTO) – the more precise definition being “the amount of time deemed acceptable for data to be restored and a solution to be made “live” once again”. The agreed RTO will determine how and where backed up data will be stored and, therefore, restored.

Combining the aspects of both RPO and RTO provides the first step in establishing the data protection or backup requirements of a solution.

Relationship of RPO to RTO

Relationship of RPO to RTO

The graph illustrates 5 different scenarios. Each scenario represents the decision a particular business has made in regards to what they will accept in terms of their Recovery Point Objective and their Recovery Time objective. With both the RPO and RTO, a lower value represents the requirement for a more stringent data protection plan.

Scenario 1
Let’s first consider the 2 scenarios which give us points 1 and 2 – a static brochure site.
We assume the acceptable RPO is high as data does not change and the original web designer has retained a copy of the site. However, the RTO is different – the site being static does not mean that it is not considered a key business asset.

Assuming high RPO, 2 outcomes are possible:
1. High RPO combined with high RTO (Point 1 on the diagram):
A high RTO here suggests that the website is not a key business asset as there is no hurry to get it back online. In this case no backup is needed – the site can be uploaded again once the server is back up and running.
2. High RPO combined with low RTO (Point 2 on the diagram)
The low RTO tells us that the website is a key business asset and it is essential for it to be restored ASAP, depending on budget.
a. High leads to a load balanced solution being employed.
b. Low budget leads to daily backups alone being employed.

Scenario 2 – a solution storing financial and accounting data (Point 3 on the diagram).
The actual data is critical and it must not be lost – giving us a very low RPO; whereas, the availability of the data is less essential and therefore the RTO is high.
a. Even with a low budget, a dedicated backup server with regular test restores is a minimum.
b. Data replication onto a separate server is recommended.

Scenario 3 – content management system driven brochure website (no ecommerce).
Clearly, the website is important to the business as they have paid for it to be updateable, and the loss of this data would result in no website content.
The result is mid level RPO and RTO (Point 4 on the diagram) as the business will be affected by the site being down and data not being restorable.
a. Low budget results in employing daily backups to give relatively fast data restore with a maximum 24 hours data loss.
b. High budget allows us to employ load balancing and database replication.

Scenario 4 – ecommerce website which is the business’ sole source of income.
The perfect example of low RPO and RTO (Point 5 on the diagram) – data loss and downtime are unacceptable.
The technologies employed depend on the budget available:
a. Even with a low budget, we must employ load balancing and data replication where the worst case scenario is short periods of downtime and minimal data loss.
b. The recommendation is a private cloud built on highly resilient hardware across geographically separated locations; thus removing any potential for data loss or downtime.