As Paul stated, I think it's more important that you just agree on and
document something.  I think it's great that you're having the
conversation about RTO and RPO.  So many environments just make it up.

I disagree that the RTO shouldn't include roll-forward time, for a
couple of reasons.  First, the app ain't ready til it's ready.  And it
ain't ready til the log roll is done.  Who cares how long your restore
took.  (You do, of course, but the customer doesn't.  They only care
when their app is running again.)

Secondly, you can do things to affect the log roll time both negatively
and positively.  For example, you could do a full backup only once a
month and say "just roll the logs."  You could also do a full backup
weekly and an incremental backup four times a day to minimize the amount
of time the log roll will take.

I think what you're saying is that if the DBAs don't do their job, then
the restore will take longer.  Fine, then they get the blame for blowing
the RTO, not you.  But saying that a RTO is met even thought the app
isn't up is semantics.  Perhaps for db apps you have a restore TO and a
log roll TO that add up to the "real" RTO.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies 

-----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: Wednesday, July 11, 2007 8:49 AM
To: Jeff Lightner; Angela Akridge; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Designing SLAs

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

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