Two most important decisions in disaster recovery – RPO and RTO


If you ever asked yourself (or management) question – what is the acceptable level of data loss, and how long it may take in case of disaster?

It means you were thinking of RPO and RTO even without knowing about these abbreviations.

RTO – Recovery Time Objective

Recovery Time Objective (or RTO in short) – is a number that defines the time that took from disaster occurred until systems were up and running again.

For example, if a disaster on a database happened at noon, and it takes 4 hours for a DBA to restore a new instance, RTO will be equal to 4 hours (RTO and RPO measurement unit is time). If Always On is being used with automatic failover, it will soon switch over to an active replica. Of course, various scenarios should be taken into consideration while measuring the recovery time objective.

RPO – Recovery Point Objective

Recovery Point Objective (or RPO) – A time gap between the last backup has been taken, and disaster happened.
As an example, the last database backup was made at 1:00, and the disaster happened at 6:00. RPO, in this case, is 5 hours.

To reduce this number – more frequent backups are needed. If data is critical, the recommendation is to set transaction log backups to 5 minutes or other small numbers depending on the environment and the actual hardware.

Make a decision

Of course, nobody wants to lose any of their data and want to have 100% uptime. However, it may neither be easily achievable nor cheap. So sometimes it‘s better to rethink business requirements if 99,99999% uptime and not 99% is really needed in your case.

Another advice – always do periodical tests of your disaster recovery setup. Sometimes numbers may look nice in theory. However, reality may be different, and RPO, RTO may be higher there. Especially if calculations were made on-premises hardware, and disaster recovery includes restoring the server environment on the cloud.

Let’s get on the call, and we will walk you through how we will keep your database safe and answer any question you have. Contact us!

Mark Varnas

Mark Varnas

I love making performance tuning SQL Servers fast and making them more stable. And I channel that obsession into our SQL Managed Services and new content here. When I'm not writing about SQL, I spend time outside hiking, skiing, mountain biking, or trying a new recipe.

Leave a Reply

Your email address will not be published. Required fields are marked *