Collocation and copy storagepool offsiting have built-in contradictions. If you
have a good offsite policy, i.e. daily, collocation can be turned on, but it
won't have any effect, since the tape that the server wants to write to will be
marked offsite and physically gone, so a new volume must be chosen anyway.
Assume 100 clients doing daily incremental, and daily offsiting. Also assume
that the new data files 10% of a cartridge. After 100 days you will have 10,000
tapes offsite if you are collocating (and using a bottomless scratch pool). If
you aren't collocating you will need just 10 tapes a day, and have just 1,000
offsite after 100 days. A restore in each case would need 100 tape mounts; the
collocated restore would be a tiny bit faster because the data would always be
at the start of the tape. But how much offsite storage can you pay for?
If you could relax the offsiting to weekly, collocation would make sense. After
100 days (14 weeks) you would have 1,400 tapes offsite and each restore would
need 14 tape mounts. But of course, a weekly offsiting schedule may not be
acceptable to your users.
I can see a new requirement here. ADSM needs a reclaim by node and time
function. One could use it like this. Use non collocating copy storage pools.
On a regular cycle, i.e.quarterly, reclaim by node all the copypool files
written in the last quarter. The result is that the number of tapes needed for
a DR restore would be a sawtooth function -- from 1 to 50, then dropping down to
5, then building up to 55, then dropping down to 10, etc. (Note - this is as far
as I am going with the requirement process).
I hope this gives you some ideas. I suspect from your question that you are
already aware of the contradictions.
Bill Colwell
The Charles Stark Draper Laboratory
Cambridge Ma.
_________________________Reply Header_________________________
Author: ADSM-L AT vm.marist DOT edu
Subject: Offsite DR Cartridges
01-27-1997 09:50 AM
We are a new ADSM shop using MVS as a server (2.1.0.10) and TLMS as
our tape management system. We colocate our onsite primary pool, but
not our offsite copypool. Onsite restores have been quite smooth, but
we fear that a DR situation would pose some issues (the number of
cartridges needed to restore a single server could be excessive).
Is there anyone out there using offsite colocation? Or is there
any way to keep less data in the offsite copypool (just keep active
files)?
Also, for a DR test or in the case of media failure, there doesn't
seem to be any way to find out what cartridges would be needed to
restore a specific node or filespace. Can anyone shed some light?
Thanks for your help.
Jim Kleberg, State Street Bank 617-985-8392
|
