Well, I can tell you from experience that your restore time will be:

     Data Transfer time
+    Tape Mount Time (library movement or (yuck!) manual mounts
+    Tape seek time
__________________________
=    Total restore time

Using a copy pool, the active files for a node can easily be spread out
over dozens and dozens of tapes.  The longest factor involved above is the
Tape Mount Time.  You may have a tape with one 1k file on it, so data
transfer time is effectively 0, but you still have to mount the tape and
position it to read the file.

Implementing a strategy to reduce the number of tapes needed to be mounted
for the restore is the best (only??) way to reduce this factor
significantly.  I implemented doing full backups on a weekly basis, and
restore times for a large filesystem went from 18 hours to 20 minutes.
Your mileage may vary, but I doubt you'll be too disappointed.

My full backups have a seperate node name attached to a seperate Policy
Domain.  At the copy group level of this, the Copy Mode is set to Absolute,
which takes a full backup.  For a restore, I restore from this node first,
then restore from the "normal" node for the updates since the last full
backup.  As I see it, if you are restoring to 6 days after your last full
backup, you should have no more than 7 tape mounts (one for the full, one
for each day since).  As I said above, the improvements were dramatic.

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?