==> In article <s0fb97e6.011 AT health-es2.health.qld.gov DOT au>, Steve Harris 
<Steve_Harris AT HEALTH.QLD.GOV DOT AU> 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