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.
