Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Voice of the DBA

Steve Jones is the editor of SQLServerCentral.com and visits a wide variety of data related topics in his daily editorial. Steve has spent years working as a DBA and general purpose Windows administrator, primarily working with SQL Server since it was ported from Sybase in 1990. You can follow Steve on Twitter at twitter.com/way0utwest

RTO in Disaster Recovery

When you have a disaster, the time that you have to restore service is usually referred to as the RTO time. This stands for the Recovery Time Objective and it can is defined like this in Wikipedia:

The Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.

That’s a great definition, covering the term with a great set of large, geeky words. However I came up with a simpler one that conveys the same information:

The time it takes for you to get things running to the point where someone can use them after someone notices that they aren’t.

You can also view the RTO as the downtime or uptime level of your system. I prefer looking at the RTO as the intervals between uptime, since I think that’s a glass half full view.

That’s the basic definition and it’s important that you determine what the RTO is for your systems in order to begin planning for the resources that you devote to disaster recovery preparation.

This post is based on the information in my Preparation for Disaster talk.


Filed under: Blog Tagged: disaster recovery, syndicated

Comments

No comments.

Leave a Comment

Please register or log in to leave a comment.