Jeff,

Excellent points! The RTO should only be how quickly the data needs to
be recovered from backup, not the entire time for the recovery of the
system.

Jason Ellis

-----Original Message-----
From: Jeff Lightner [mailto:jlightner AT water DOT com] 
Sent: Wednesday, July 11, 2007 6:08 AM
To: Ellis, Jason; Angela Akridge; veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] Designing SLAs

Make sure "RTO" part of the SLA deals only with the restore from backup.
For a large DB the full "recovery" time will include rolling logs and
other activities performed by the DBAs AFTER the restore from backup is
complete.  It is important you note your SLA doesn't cover activities
after the restore from backup to bring the app/db operational again (or
that if it does that you've factored in these additional steps).

Nice information Jason.

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Ellis,
Jason
Sent: Tuesday, July 10, 2007 5:00 PM
To: Angela Akridge; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Designing SLAs

Angela,

A couple of the things that you want to define in a backup SLA are
Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). 

Recovery Point Objective (RPO): How much data can you afford to lose and
still be able to survive and/or be compliant?

Understanding how much data loss is acceptable for a particular system
or application can have a major impact on how that system or application
is protected. The RPO of a system can help to set the importance of
backups and help to determine what an acceptable error rate is. For
example: If your RPO is 48 hours, then as long as you have a successful
backup within the 48 hour windows you are in compliancy with your SLA.

Recovery Time Objective (RTO): How quickly does a specific system or
application need to be recovered?

RTO is the period of time within which systems or applications must be
recovered after an outage. Know a system's or application's RTO can help
determine whether copies of the data need to be maintained on-site for
quick recoveries. An RTO can also help to set the importance of restore
requests.

Hope that helps!

Jason Ellis

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Angela
Akridge
Sent: Tuesday, July 10, 2007 11:36 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Designing SLAs

Hi!

Do you have any web sources that provide excellent best practices
about how to design an SLA for backup duration and restore duration?
What is a reasonable backup duration and restore duration? Storage
Magazine has plenty of articles, but not really anything that I can
"sink my teeth into."

(CISCO has detailed best practices, but the SLAs are specific to
networking:
http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper0918
6a008011e783.shtml.)

Thank you,

Angela
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu