I'd recommend trying to Move Data from the tape before setting it as destroyed.
This will reduce the amount of data you have to restore from the Copy pool.
Especially if the copy pool is located off-site, so that you won't have to
retrieve as many volumes (hopefully).

I have had instances where, after doing the Move Data, running an Audit Volume
with FIX=NO (the default) will "recover" some of the files, and they can be
moved off the tape.  Then another Audit Volume, another Move Data, etc. until
the tape was empty!  When it takes a few hours to get a tape back from the
vault, you have time to play...

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?





If you DELETE VOLUME, then you will lose the copy stg pool version.  This is
okay for files still on the client, but is fatal for inactive files.  Rather,
UPDATE VOLUME xxxxxx ACCESS=DESTROYED.  Then, when you need to restore, the
ADSM server will ask for the offsite copy volume rather than the on-site
primary volume.

In addition, after marking volume xxxxxx destroyed, you can issue a RECOVER
VOLUME command to get the files from the offsite tape.  There should be a
PREVIEW=YES option to RECOVER VOLUME that will tell you which offsite tapes
you need to bring back for the operation.

Rich