More parameters you have to put more choices are available and more
flexible the product is.
Some people want to be able to make more than one stgpool backup in more
than one copy pools. You suggestion would limit them.
Why not to create few simple scripts called BACKUP_BLOTZMO, BACKUP_WAKKO
and BACKUP_AAGRAVAAG or even a single "bigger" script
BACKUP_ALL_THIS_STUFF_youre_the_computer ?
Zlatko Krastev
IT Consultant
asr AT UFL DOT EDU on 13.11.2001 01:38:09
Please respond to "Allen S. Rout" <asr AT ufl DOT edu>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Aggravating recordkeeping failure in TSM.
How do YOU keep track of what primary stgpools _ought_ to be backed up? Not
what are we doing, but what should we be doing?
There's a set of data that we all need to keep track of, which TSM simply
punts: 'where should this primary stgpool be backed up to?'.
I don't know about most of you, but I have stylized stgpool names, which
let
me identify candidate copy pools from nomenclature alone.
YADDA-DISK
YADDA-TAPE
YADDA-OPTICAL
all back up to
YADDA-C1
and
YADDA-C2
and so forth, if they are there.
But this is an immensely clumsy way to do it. I want a way to set, in the
TSM
database, the notion "BLOTZMO-DISK, WAKKO-TAPE, and AAGRAVAAG-OPTICAL
should
be backed up to ARCHIPELAGO-MOOSETHROTTLE". Then I could issue a command
of
the sort:
back stgpool BLOTZMO-DISK figure_it_out_youre_the_computer=yes
Not only does the lack of recordkeeping make it impossible to do automatic
maintainance as I suggest, it makes it a priori impossible to write a
monitoring tool without maintaining some sort of external configuration
file
to hold the data.
This could be solved officially from the inside, or it could be solved by
letting us add "columns" to the "table" STGPOOLS. We could come up with
standardized names for this kind of data, and we'd at least be able to do
-something- with the base package. Heck, even a single-value field
BACKSTGPOOL to match NEXTSTGPOOL would be something. Of course, to do it
BACKSTGPOOL to match NEXTSTGPOOL would be something. Of course, to do it
right you'd want a relation: there's no technical reason to prevent peole
from
backing up all their primary stgpools to all their copypools.
Allen S. Rout
NERDC TSM admin
|
