Think of it this way Paul. (and please excuse me if I pitch this at too
low a level)

You are trying to create an offsite point of consistency every day.  So,
you run your backups overnight, then copy the data to your copypool.  At
this point you should create a DB backup - I prefer to use the classic
DB backup for onsite recovery and a DB Snapshot for offsite - then eject
the current copypool tapes and the DB snapshot from the library. Finally
create a plan file and get it offsite by your preferred method.

When the meteor hits your primary data centre, you take the offsite
tapes and the plan file to your new hardware.

Unpack the plan file and it will tell you whilch database backup tape to
use.  Restore the database and you are right where you were at your
point of consistency, so all the data from that night's backup is on the
offsite tapes that you have.  Then you can start your client restores
and stgpool restores.

If you don't have some of the copypool tapes then you will not be able
to restore some part of the data. So unless you maintain both an onsite
copypool and an offsite copypool for the same data, you need to eject
all of the copypool tapes every day.

This means that 1 tape per copypool per day will go offsite
part-filled.  When reclamation starts you may see the tape you just sent
offsite get reclaimed.  No matter, the database snapshot that is with
that tape is consistent.

Two other things to watch with reclamation.  If you run offsite
reclamation the "new" way with the reclaim command it will finish after
examining the number of tapes specfied in the offsitereclaimlimit
operand of the command or the same property of the storage pool.  There
is also a bug in 5.5 that affects the selection of offsite volumes for
reclamation.  For these two reasons, I have reverted to the traditional
method of setting and resetting the reclaim property for the storage
pool, as this will restart itself as necessary until all tapes over the
threshold have been reclaimed.

I hope this helps

Steve

Steven Harris
TSM Admin
Paraparaumu, New Zealand





On 22/10/2010 6:24 PM, Paul_Dudley wrote:

Thanks for the reply but one thing I am still confused about are these copypool 
tapes sitting in my onsite tape library. Given that the primary reason for this 
copypool is for offsite tapes, should these copypool tapes currently residing 
in my tape library (created by reclaimation processes) be checked out and sent 
offsite as well?

Thanks&  Regards
Paul

-----Original Message-----

A lot of these have a status of "Full" however they are only 50/60/70% used.

...a reflection of files on the filled tape expiring over time, which 
reclamation will
combine with other data to fill a new tape.  Surrogate reclamation tends to be 
quite
slow compared to direct reclamation, where it may not be able to keep up with 
the
need for additional offsite tapes for new data, the result being a considerable
demand for the scratch tapes you have in the library, which could account for 
your
issue of running low on scratch tapes.

The only other suggestion that may apply is to verify the devclass Format being
used, that it uses compression so as to get the most onto the tapes.

     Richard Sims

        
ANL DISCLAIMER

This e-mail and any file attached is confidential, and intended solely to the 
named addressees. Any unauthorised dissemination or use is strictly prohibited. 
If you received this e-mail in error, please immediately notify the sender by 
return e-mail from your system. Please do not copy, use or make reference to it 
for any purpose, or disclose its contents to any person.