G'day Mike,
I'm not necessarily advocating that you do this, but if you wanted to...
make your jbod pool a sequential file-based copy pool.
daily, after your backups are complete run a backup stg primary pool->jbod pool
when this has finished, mark all of your jbod pool volumes read only
as part of housekeeping, run a del vol <volumename> discardd=yes on any volumes
in jbod pool that are over 3 days old. This will require some external
scripting.
Regards
Steve Harris
TSM Admin
Queensland Health, Brisbane Australia
>>> mikee AT MIKEE.ATH DOT CX 16/11/2004 10:01:56 >>>
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
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the
sole use of the intended recipient(s). This confidentiality is not waived or
lost, if you receive it and you are not the intended recipient(s), or if it is
transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is prohibited. It may be subject to a statutory duty of confidentiality
if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email in
error, you are asked to immediately notify the sender by telephone or by return
email. You should also delete this email and destroy any hard copies produced.
***********************************************************************************
|
