==> In article <[EMAIL PROTECTED]>, Steve Harris <[EMAIL PROTECTED]> writes:
> There was another management requirement that all production servers be > backed up in full once per year and that snapshot be kept "forever" - there > is no reasoning with this, its one of those stupid mandates that applies to > the whole of the state government, and if data is not able to be > categorized, then it must be kept. Mmm, Arbitrary. Tastes like BUDGET! > I think you'll recognise that having a third TSM Server for the yearly > backup isn't really an option, so an archive mechanism is the only one that > will work for that. Actually, I'd disagree that an extra server is a barrier. The reason is that I am finding it to be very simple to maintain several servers on the same hardware. Right now I've got ~10 on one box, and it works quite well. Though, really, you can use a seprate policy domain instead of a separate server perfectly easily. But I like the separate server scheme... So, permit me to spin a yarn for you, which I will assert will solve your monthly and your yearly-forever problems all in one swell foop, and at a lower cost in management and consumables than your archive scheme. Erect on your TSM server a second TSM instance. I'll call it the ARCHIVE server. On the ARCHIVE server, define nodes for those machines getting the cast-in-stone treatment; On their management classes, define: verexists 1200 verdeleted 1200 retextra nolimit retonly nolimit On each of the client machines, add an ARCHIVE stanza to your dsm.sys. Then, run incrementals for each box once a month. In unix land, I'd say 1 0 1 * * dsmc incr -se=ARCHIVE in your crontab. Now, I recognize that this is only retaining data for 100 years, but what the heck, the pig may learn to sing. ;) You get all the benefits of the incremental scheme, you separate the archive/retention database from the recovery database, and you don't waste any hardware. There, I assert. Please pick holes. - Allen S. Rout
