At 10:32 AM 7/30/2004, Robert R Price wrote:

I know that I must be missing something here, but can someone explain why
this D2D backup scheme utilizes what I assume to be the sequential FILE
device type?  Why not just use the (random) DISK storage pool type.  This
would eliminate any co-location issues, reclaims and not waste ANY disk
space with deleted files?  Would someone enlighten me?

I haven't been following this entire thread, but so apologies if someone
has already pointed this out.

Heavy use of DISK storage pools, as opposed to sequential FILE stgpools,
can be a problem if you ever have to restore your database.  I know this is
rare, and some folks think that this will never ever happen to them (I used
to be one of them), but in fact it is a real possibility.  After you
restore your database, you must audit all of your (random) disk volumes,
and any tapes which may have been reused subsequent to the backup you are
restoring to.  The latter problem can be avoided by using the "reusedelay"
attribute on the storage pool.  But for disk storage pools, there is no way
around auditing them.  The more you have, the longer this will take, and it
can take a long time.  If you are use sequential FILE volumes, with
reusedelay, this avoids this problem.

..Paul



--
Paul Zarnowski                         Ph: 607-255-4757
719 Rhodes Hall, Cornell University    Fx: 607-255-8521
Ithaca, NY 14853-3801                  Em: psz1 AT cornell DOT edu