SQL Server RPO and RTO

Disaster Recovery RTO RPO or Business Continuity RTO RPO is very important for a Business Recovery time needed to recover if a disaster seemed to happen. Time needed for Business data recovery is RTO. This can be minutes to hours depending on where the DR Site is located and backups are located.
Disaster Recovery RTO RPO

Recovery Point Objective(RPO) describes a point in time that data can be restored from. For instance, if there is data corruption, Data loss or unavailability, at what point in time can a valid copy of the data be restored from? RPO is usually measured as minutes, hours, days, weeks, etc… for Business Continuity.

If a database is corrupted then can we restore it back to what it was 15 minutes ago? This would be an RPO of 15 minutes for Business Continuity..

Recovery Time Objective (RTO) is the amount of time which data or hardware is desired to be restored after a data corruption or hardware failure.

If a Database server just died. Time needed to bring it up and running again? If the answer is one hour then the Recovery Time Objective is one hour.

In a situation when a disaster occurs, the only main thing is to be bring the application available to users. There are many ways to make sure the applications can be brought back online like
1. Building DR site for Critical application. I would recommend not to have a automatic failover for DR but instead make sure that the steps needed for getting DR Site online needs to be documented. This can be SAN Based replication or SQL Database Mirroring or Clonning application server on DR Site etc.
2. Storing Tape backups offsite both SQL and Virtual machine backups if any.
3. Having online data replication by using any of the known data distribution/replication methodologies to be available in case of Disaster. This can be easily done for Multi Site companies by having a local copy of data at every Site.

RTO and RPO needs to be defined with SLA(Service Level Agrement) to define the amount of data loss tolerable in case of disaster and how much time is tolerable to get the services up and running for Business Continuity.

To make sure Disaster Recovery RTO and RPO is covered fully some important steps are SQL Server Full backup, Differential backup, SQL Server Transaction log backups, physical server backup, server backup using any other backup application and cloud virtual server backup etc. Only way to make Business Continuity RTO RPO are covered is to do test Restores from time to time to make sure backups work.

The articles used in designing different backup and restore stategies for Achieving RTO, RPO, SLA are:
Different Backup options in SQL Server 2008
Different Restore options in SQL Server 2008
SQL Server 2008 Recovery Models and Transaction log usage

Leave a Reply

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