Introducing RPO and RTO
Knowing your RPO (recovery point objective) and your RTO (recovery time objective) is absolutely vital when it comes to disaster recovery planning. You’ll want to have a clear idea on what the two terms mean and how to distinguish between them, because they’re the essential KPIs that you’ll use to dictate your disaster recovery guidelines.
RPO (Recovery Point Objective)
RPO is used to refer to the maximum possible time period in which data can be lost after a system failure. If your RPO is ten days then that means that any database outage should compromise a maximum of ten days’ worth of data.
This parameter should consider how much data can be lost without hampering normal business operations, and it helps to determine which files should be backed up – and how often. It’s useful when it comes to system administration because it gives your team a definite target to adhere to.
RPO Real-Life Example:
Imagine that you host an e-commerce website that receives an average of one transaction every three hours.
If you’re forced to restore your database from a backup, you want to lose as few transactions as possible.
Dealing with one lost transaction might be manageable, but dealing with eight would cause more of a problem.
In this instance, you’d want to set your RPO at three hours (or shorter) to minimise damage.
A daily backup wouldn’t be good enough.
RTO (Recovery Time Objective)
RTO follows a similar principle to RPO, but it refers to the target time-frame within which a system should be restored after a disaster.
In most instances, it’s essentially a service level agreement designed to protect the business continuity of your hosted website or application.
Accidents – and disasters – happen, and no webhost can honestly guarantee 100% uptime. That’s why it’s important to set an RTO – so that you know that your system can be restored in time to avoid any long-term repercussions.
Setting an RTO is the first step towards damage limitation when something goes wrong.
RTO Real-Life Example:
For this example, let’s pretend you run a smartphone game. How long can you afford for components of your stack to be down?
After how many hours of downtime will your users be so frustrated that they’ll delete your app and try something else?
It’s vital to define your expectations of how much downtime you can realistically afford to endure so that your support team has an objective to work towards.
RTO helps define your expectations of how much exposure time you can afford to endure.
Every minute you’re offline means a higher risk of bad publicity, angry customers, and lost revenue.
Disaster Recovery Planning
They say that if you fail to prepare, you prepare to fail.
That’s why it’s so important to establish a disaster recovery plan ahead of time – so that if something does go wrong, you’ve got an established protocol to fall back on.
Most web hosts back up their customers’ data, but sometimes data needs to be archived on different schedules. Sometimes it’s better to continuously make backups through replication.
Unfortunately, there’s no one-size-fits-all approach, which is why you’ll need to work closely with your web host to figure out what will work best for you and your business.
Everyone’s disaster recovery plan is unique. Every year, many organisations lose a lot of data,either due to a data leak or an unplanned removal or other technical reasons. It is recommended to use disk drill data recovery software or something similar to fix this problem and avoid data loss.
The most important thing is to have one – after all, the absence of written guidelines will dramatically increase the risk of disappointment during a disaster.
That’s why you’ll want to work with your web host to write, approve and deploy a full disaster recovery plan that actually works. Be sure to ask them about their capabilities before you sign a contract and start working with them.
Want to work with us?
If your data is business-critical, we can help.
EuroVPS has the experience and infrastructure needed to support a wide range of business continuity requirements.
From a simple offsite backup setup to large projects with real-time replication and clustered configurations, we know what it takes to get the job done.
