ADSM-L

Re: AW: Incremental Forever

2000-05-03 22:13:12
Subject: Re: AW: Incremental Forever
From: Nick Cassimatis <nickpc AT US.IBM DOT COM>
Date: Wed, 3 May 2000 22:13:12 -0400
Prioritize, prioritize, prioritize.  Plan the restores out so they won't be
stringing each other along.  If Node2 is dependent, operation-wise, on
Node1, then plan to restore Node1 before you start Node2.  You should be
able to plan out the order the machines are needed in, and then, when you
do a Disaster Recovery Test (you are doing them, right?), see how your plan
actually works.  Fix, and repeat as necessary (or allowed).

Nick Cassimatis
nickpc AT us.ibm DOT com

"I'm one cookie away from happy." - Snoopy (Charles Schulz)

Subject:  Re: AW: Incremental Forever



And another thing  :-}   ----
In the event of a site disaster, won't there be lots of tape contention?
i.e. you try to restore 10 nodes in parallel, but 4 of them need the
same tape, and the first of the four to get the tape locks it until its
restore is completely finished.  Thus the other three have to wait.
(Unless you collocate your copy pool - not recommended.)

Right?

Backup sets solves this one too.  But you'd have to make backup sets of
EVERYTHING on a regular basis.... Ouch!

Anybody have a better scheme for handling tape contention in a DR
scenario?
<Prev in Thread] Current Thread [Next in Thread>