Nick,

The best design (in my humble opinion) is to have an onsite collocated
pool (to which I was referring) which would be used for all recoveries.

The offsite copy as you say is best without collocation, however this
is ONLY used in the case of a major disaster (ie you lose all your
onsite tapes) or if you have one or more onsite tapes die for some reason.

You can then use the offsite copies to recreate your onsite tapes or
pools, which would take a while if you have to recreate everything, but
then we are talking about a major disaster for this to occur (by the
way if you need to do this generally the most efficient way will be to
recover to an onsite disk pool, and let the migration handle the
movement to onsite tape pool - this will reduce the number of tape
mounts drastically).

Regards,
Simon
----------
| From: nickpc /  mime, , , nickpc AT US.IBM DOT COM
| From: nickpc /  mime, , , nickpc AT US.IBM DOT COM
| To: ADSM-L /  mime, , , ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: Restore times
| Date: Monday, 06 December, 1999 8:42AM
|
| No, collocation on the offsite pools is not feasable - I'd have tapes
| shipping offsite with 1 or 2 files on them.  With 3590 tape, that gets
| expensive fast.
|
| And your data is still spread over tapes - one for every offsite shipping
| period (usually daily).  So you have more tapes offsite, but with less data
| on each one.  It really wouldn't speed up the restores much at all.  That's
| why I didn't go to collocation - it just didn't make sense.
|
| I have a certain number of systems that are Disaster Recoverable - they are
| contracted to be back online within 72 hours of a disaster being declared.
| Those are the ones that I do the weekly fulls on - the "non-production"
| machines only get daily incrementals, since the restore time on them
| doesn't matter.
|
| Nick Cassimatis
| nickpc AT us.ibm DOT com
|
| If you don't have the time to do it right the first time, where will you
| find the time to do it again?
|