Hi Paul!

On Mon, 15 Nov 2004, Paul Zarnowski wrote:

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

Honestly I don't yet know how or if it will work. The data flow
I'm thinking of is:

node -> primary storage pool -> tape pool
                             -> tape copy pool
                                                         -> JBOD pool

Once the node has sent it's data to the storage pool, then the
storage pool migrates everything to the other three pools. The
JBOD just expires; does not migrate to another pool. Is there
someway to create a priority or hierarchy of restoration methods
such that the JBOD is checked first for the files, then the
tape pools are checked?

What started this is an estimate from a windows gui that to
restore ~225GB of data would take ~105 hours. The windows admin
finds this unacceptable. The goal is to restore most of the
data in a short amount of time, say restore the fileset in
5-6 hours (fourth point of contact), with (or not as needed)
incremental updates to follow.

Mike