Excellent run down on pros and cons.

From our testing, this feature works very well.  A couple of keys: pick
specific nodes.  I don't think you want to do this for all systems as the
generation of the backup sets is pretty strenuous.  Ensure you have the
proper media type for the restore.  You can also write the info to CD which
may make it a bit more portable than tape (lots of CDs, but those are cheap
these days).

I like another approach as well.  Rather than over worrying the restore of a
server, start to fixate on restoring applications and data.  For instance,
in most shops, the most critical application has something to do with money:
money in or money out.  So the finance app is most critical.  If you focus
on the data and app for finance, and make sure that is optimized for
disaster restore, you can probably shorten the time to making this app
functional again.  Take your average large server: a couple of hundred gigs
maybe.  How big can the finance app and data be?  20 - 50 GB?  Restoring
20 - 50 GB is an easy problem.

Proceed like this covering all the mission critical apps.  The nice thing
about apps like these is they tend to somewhat naturally collocated on the
primary and copy storage pool tapes due to the way they are backed up: shut
'em down and back 'em up.  Nothing special required to ensure data is on
just one tape.

The downside of this approach to the rapid restore approach is you must have
the *SM server to do the restore.

When faced with the prospect of eating a whole elephant, the task can appear
daunting.  However, if you eat him a little at a time, you won't get a
stomach ache.  Divide and conquer folks.

Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80919
(719)531-5926
Fax: (719)260-5991
www.storsol.com
lipp AT storsol DOT com