Yep -  Just like anything else, if you make a change and don't decide it's a
bad change until all your backups have expired, you're toast.

I think to some degree it's a change-control issue.

One thing you can do is use ntbackup to create ANOTHER copy of the system
object stuff with a unique name in a flat file on the server, then let TSM
back that up - or archive it with an expiration date of say 30 days, or 60.

That will give you an "out of band" copy of the system object stuff, that
won't get stomped by TSM's daily versioning.








-----Original Message-----
From: Magura, Curtis [mailto:curtis.magura AT LMCO DOT COM]
Sent: Wednesday, April 23, 2003 9:45 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: System Objects Again


A topic that has been discussed many times.... System Objects! We are
looking at reducing the number of System Objects that we are keeping.
Currently they are managed using the same rules as the rest of our data and
taking up a fair amount of space on the TSM server side.



When we started discussing the option of putting the System Objects into a
different mgmt class with less copies maintained with the Intel support team
they raised a question. Looking for feedback from others on the list and how
you handle. In our case most of our Intel servers are rebooted on a weekly
basis. A handful of servers are not rebooted on this schedule due to the
backups still running during the maintenance window when we could perform
the reboot. The reboot schedule of these machines is "as required" rather
than on a scheduled basis.



If there is a major change taking place the machine would be rebooted to
ensure that it is still bootable right after the change was implemented. So
in this case you would know that you have a problem and could restore as
required to get the machine back into a usable status. Let's say that a
change is made that affects the information that makes up the System Object
and either you don't know that took place or you are not able to reboot that
machine for some reason until after the number of days has exceeded the
number of days of System Objects that you maintain. At this point you have
no way to recover? Is that the correct assumption? The obvious answer is
making sure that the machine is tested and bootable after all changes.
Perhaps not a TSM issue but a change control procedural issue. While I can't
control all of the change mangement issues I do need to ensure that I can
provide the ability to restore a machine from a change gone bad.



What are other folks doing in this case?



Curt Magura

Lockheed Martin EIS

Orlando Fla.

321-235-1203