We have a script and it does a move data on any tape (primary or copy)
that is older then (not read or written in) x days.  We are currently
using 6 months as our x.  This makes sure that offsite tapes do not sit
for 7 years also.


--
Phillip
(901)320-4462
(901)320-4856 FAX



-----Original Message-----
From: Allen S. Rout [mailto:asr AT UFL DOT EDU] 
Sent: Wednesday, August 16, 2006 9:20 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Lots of newbie questions


>> On Tue, 15 Aug 2006 14:34:49 -0500, Troy Frank 
>> <Troy.Frank AT UWMF.WISC DOT EDU> said:


> Where would you draw the line with this?  For monthly snapshots, 
> you're saying it works better than archives/backupsets.  Would you 
> also extend this to replacing yearly archives that need to be around 7

> years?  I don't see why not, but I've not spent as much time mulling 
> it over as you probably have.


Yes; in fact we're setting about doing just such a thing.

In this environment, I expect a (to us) totally alien concern to be the
most important: Tape reliability. You wrote EOT of tape number one; You
will now not touch that tape for seven years, or it's copy volumes.  How
do you assure yourself that the data is legible?

For live data, we usually have churn in our tape pools; expiration and
reclamation usually cycle through the entire corpus of tapes in a
reasonable timeframe.  Long-term storage of static data blows that
model.

Once framed that way the solution is obvious: when possible, take the
"oldest" tape you've got and MOVE DATA on it.  If you can do this a few
times a month, You will sharply curtail the possibility of a write-only
volume.



- Allen S. Rout
*********************************************************************
This message and any attachments are solely for the
intended recipient. If you are not the intended recipient,
disclosure, copying, use or distribution of the information 
included in this message is prohibited -- Please 
immediately and permanently delete.