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 our expert SQL Server Consulting team handle the technical complexities, so you can focus on driving your business forward with confidence.

Picture of Mark Varnas

Mark Varnas

Hey I'm Mark, one of the guys behind Red9. I make a living performance tuning SQL Servers and making them more stable. I channel my SQL into our SQL Managed Services, SQL Consulting and our internal database products.

Leave a Reply

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