=> On Fri, 16 Nov 2001 14:34:52 +0200, Zlatko Krastev/ACIT<[EMAIL PROTECTED]> 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. > [EMAIL PROTECTED] 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
