I'm just thinking out loud on this one...

Taking the primary pool tapes off-site will work.  When you check them out
of the robot, make sure they get marked unavailable (sort of hard not to)
so that ADSM will use the copy pool tapes for the restore.  Or fetch the
tapes from the off-site and do the restore from them.  If you use the copy
tapes, you're probably looking at a long restore: 160 GB divided by 30
GB/hour over 100 M network = 5.2 hours or so, downhill, wind at your back.
 But if it takes two hours to fetch the tapes, you're probably money ahead
doing it this way.

You're mostly worried about the restore on this one, right?  I can't divine
a way to get three copy stg pool tapes.  How about another robot with
smaller capacity tapes?  DLT4000s.  How about creating another device class
in this robot with format=20C instead of format=35C.  I think you would
have to assign volumes to the pool that used this class instead of using
scratch tapes to satisfy volume requests.  I'm getting way out here now,
but, hey, this requires some deep thinking!  I'll leave the implementation
to the reader.

My next question would be can a really multi-stream the restore?  Can I
really use more than one tape effectively?  How are you doing the backup to
three tapes simultaneously?  Three streams from the client, or are you
using migration from a very small disk pool?  If you're using three
streams, you could use three different primary/copy storage pool
hierarchies.  This might have an effect on your backup stg commands but may
result in a quicker restore since you could start three streams to do it.

Sorry about the stream of consciousness, but hopefully some it will spur
the right thoughts.

Kelly Lipp
Storage Solutions Specialists, Inc.
lipp AT storsol DOT com
www.storsol.com
(719) 531-5926