At 11:11 AM 11/15/2004, Stapleton, Mark wrote:

From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of Mike
>We have a few servers where the TSM GUI estimates nearly 3.5
>days to restore all the files. We're talking now about getting
>something like a JBOD as an additional copypool (is that the
>right term?). The data flow would be node->storage pool->tape pool
>                                     ->JBOD copy pool.
>
>The JBOD copy pool would self-expire after 3 days (depending
>on how much is actually stored to the JBOD.
>
>With the nightly backups copied to the JBOD, would this
>help/speed up a catastrophic restore (catastrophic of the
>node, not of TSM)?


I'm curious as to how you plan to "self-expire" the JBOD copy pool.
Remember that there will be as many files in the copy pool as there is
in the primary pool.

Mike,

I don't see how what you are proposing would work - I have the same
question that Mark has.  Also, TSM will not restore directly from the copy
pool UNLESS volumes in the primary pool have been marked destroyed.  I
don't think this is what you're looking for.  However, you might consider
the following instead:

Data flow: node -> JBOD storage pool -> tape pool
                                     -> tape copy pool

For the JBOD storage pool, use a MIGDELAY of 3 days.  This will ensure that
objects stay on the JBOD storage pool for at least 3 days before being
migrated.

Be careful - if your JBOD storage pool is random access and gets large,
then if you should ever lose your database, the time required to perform an
audit of all of the JBOD volumes could take a very long time to
complete.  As with many things, there are tradeoffs to consider.

..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