=> On Fri, 16 Nov 2001 14:34:52 +0200, Zlatko Krastev/ACIT<acit AT attglobal
DOT net> said:
> More parameters you have to put more choices are available and more flexible
> the product is.
Well, yes; exactly. :)
> Some people want to be able to make more than one stgpool backup in more
> than one copy pools. You suggestion would limit them.
Not at all.
> asr AT UFL DOT EDU on 13.11.2001 01:38:09 said:
>> 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.
If done correctly, there should be copy-pool associations just like schedule
associations. As I said, there's no technical reason not to back up all
stgpools to all copy pools. Practical reasons, but no techical obstacles.
> 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 ?
I think you missed my point: This does not solve the problem of maintaining
the data "which primary pool should back up to which copypool". I would still
need e.g. an outside database that maintains that data, and periodically
verifies that the right scripts are defined.
In fact, the method you describe is the method I use on my server right now: I
maintain an outside authority, which happens to be an XML file mapping stgpool
heirarchies and copy pool correspondences. From this "canonical source", I
generate backup scripts of various sorts, which are loaded into TSM on a
periodic basis by administrative schedules. Other administrative schedules
run the scripts so generated.
All of this is baroquely complex, given that very simple additions to the data
model would let all that information live _inside_ TSM. Even if Tivoli
decided not to make the
BACK STG source figure_it_out=yes
command availiable, we'd at least have a common background in which to frame
our discussions. This would help understanding and promote best practices.
How many of you happen to be using XML and PERL to manage your copy pools?
Not many, I bet. We'd have more to learn from each other if we were doing it
more the same way. Tivoli is the obvious source of authority for that way.
Allen S. Rout
|
