Andy,  actually my question is reality from my learning experiences.  The
client in question has 3 incremental backups of same files at 40GB x 3 =120GB.
The client has no other backups as it has been in test-mode and this was a
situation where we needed to save these files for 7 days  "then we can scratch
them".    So, great, I changed the policy to extend the retention period to 7 .
Well, on day 4 voices are saying loudly. . "we need to keep them 'til  October
31st".   So, I stopped the daily incremental backup as well expiring inventory,
deleting old db backups, etc. I did a point-in-time recovery back to the last
of the 3 days I need to preserve.   Now, I need to deal with the 3 days of
backups and Bill's work-around seems like a perfect fit. I'll rename the
existing client, etc., set policy to expire these files after 10/31. Then I can
define a new node with the original name and continue with normal backups.  So
to the novice ADSM'r (me) Bill's workaround seems like a perfect perfect fit
and will save me a lot of time and work.

Thanks for your interest and help.

  Don Daniels






storman AT us.ibm DOT com (Andrew Raibeck) on 09/17/98 04:52:49 PM
To: Donald W. Daniels/FFIC@FFIC
cc:
Subject: Re: ADSM expectations too high??

Hi Don,

Just one caveat with this work-around: depending on the circumstances (and
it sounds like your question was hypothetical and that you weren't actually
facing this yet), the node may actually have hundreds of GB, or even TB of
data stored. There may be many versions of each file, depending on your
copygroup settings. If the data you need to preserve is only a subset of
the total (i.e. 120 GB out of 900 GB), then the cost of doing so is that
you'll be keeping an extra 780 GB of data around for longer than you need.

After thinking about it, maybe your question was geared to preserving *all*
data for a particular node? I was thinking that it was a case where you backed
up 120 GB, say, over the weekend, and then you decided that you wanted to
keep *only* those 120 GB and not all filespaces.

For example, let's say I have a 100 MB file called FOOTBALL.SCORES and I back
it up daily. Maybe I want to keep a season's worth of scores, so I have the
versions set to 120. This means that I could be consuming up to 12 GB
(100 MB  x  120)!

Now if I decide that I want to keep the last FOOTBALL.SCORES file of the season
for 7 years, then the work-around would mean that I am actually keeping 12 GB
of data around for 7 years!

If I know I only care about the most recent version, then I could do what was
suggested, except set the NOEXPIRE copygroup such that EXTRAVERSIONS=0 and
RETONLY to forever.

Well, these types of scenarios could go on and on, but I figured I'd mention
that one caveat.

Thanks for listening,

Andy

Andy Raibeck
IBM Storage Systems Division
ADSM Client Development
e-mail: storman AT us.ibm DOT com

Andy, thanks for the information. I will, as you recommend, pursue adding our
voice to the requirement.   Thanks to listserver participant Bill Colwell, I
now have a very nice work-around solution to avoid the  unthinkable
restore-then-archive exercise.
   Don Daniels
   Firemans Fund Insurance Company