John Schneider wrote:
> Greetings,
>     I would like y'alls input on how to handle tape rotation offsite.
[Part of original message deleted]
> 2) I could always do 'delete volume' on every tape that is
> due to come back.  If I do it a few couple days before it
> actually comes back, new copies of remaining active
> data will be generated and sent offsite before the volumes
> are sent back.  This looks promising, but I can't see any
> easy way to figure out within ADSM which tapes need
> to be deleted.   You can't do a "delete volume date=today-14"
> or some such command, at least I can't find a way.  I could
> write some mechanism outside of ADSM to record the volumes
> by julian date when they are checked out, then two weeks
> later delete them.  But that requires a bunch of date
> calculations in code, and sounds error prone, especially with
> Jan 1,2000 coming along.

I use the following command to find tapes that were written more than 21 days
ago:

select volume_name, last_write_date from volumes
where (stgpool_name='DBVTS' or stgpool_name='BYFS') and
status<>'PENDING' and
(cast((current_timestamp-last_write_date)days as decimal(4,0)))>21
order by last_write_date")

Line breaks have been introduced for readability. Depending on the overall
design of your client's tape management, you might prefer to select on the
basis of the chg_time field or the upd_date field in the drmedia table.

> Also, it scares me to build 'delete
> volume' commands into a script, since I won't be the person
> to monitor whether it is working on a regular basis.  What if
> for some reason we went a week without getting any copy
> storage pool tapes sent offsite?  This script would be
> merrily chugging along, deleting all our offsite tapes!

It is not clear to me that the presence or absence of 'delete volume' commands
has any affect on the integrity of the system if production of new offsite
tapes stops for a while. If old tapes continue to return from the vault, some
of the data needed for disaster recovery will no longer be available offsite,
regardless of what the onsite copy of the database says about the status of
the tapes. If the return of tapes stops, the last offsite copy of the database
and all of the copy storage pool tapes it refers to will remain in the vault
indefinitely, and it will be possible to restore client systems to the state
they were in just before the last offsite copy of the database was written.
This is the best outcome one can hope for if the flow of new offsite tapes
ceases.

A third approach to reclaiming the offsite tapes that are about to return is
to perform a 'move data' command for each such tape. This has one serious
disadvantage. If two or more 'move data' commands need input data from a given
onsite tape, that onsite tape will be mounted two or more times. I think both
of the approaches mentioned in the original posting do a better job of
optimizing input tape mounts.

Does the client organization understand the implications of the rotation
scheme in terms of the number of tape mounts required for disaster recovery?
As far as I can tell, restoring a population of files that is subject to
sporadic changes is almost certain to require 14 or more tape mounts.