You would think if TSM is storing each system file that is backed up as a
separate object in the Database, that it would be smart enough to only back
up the "system files" if any of the individual files had changed.
Have you tried submitting your requirement to the ADSM-R list also?
My personal beef with system ojbects is that I can't archive them. We use
archives to do bare metal restores also so this leaves us also looking at
other solutions. Currently we use MS backup to backup the system state to
local disk then we can archive that file. This also could be used as an
alternative to backing up the system ojbects with TSM. (With 4.12 you would
have to change the domain statement to not backup the system objects and
specifically specify the drives you needed backed up.) You still have the
same amount of data being sent every night (which may not be a big deal to
you but it is to us!) but now it is only one object in the database. This
now of course changes you bare metal restore steps, but basically you just
replace the "Restore System Objects" with TSM to "Restore System State
Backup" with MS backup. With Domain Controller restores in W2K we are doing
the system state bakups with MS backup as additional insurance because of
problems we have run into doing bare metal restores relying on System
Objects backed up with TSM.
Tim Rushforth
City of Winnipeg
-----Original Message-----
From: Prather, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 01, 2001 3:24 PM
To: [EMAIL PROTECTED]
Subject: Issues with Win2K SYSTEM OBJECT/SYSTEM FILES backup
I have run into some ugly issues with the Win2K backup of the "SYSTEM
OBJECT".
I'm throwing the information out here to warn other people what to expect,
and hopefully to get the developers to reconsider the current
implementation.
The SYSTEM FILES component of the "SYSTEM OBJECT" on Win2K consists of over
1500 .dll and .exe and .obj files from (mostly) the WinNT/system32
directory. These files are backed up EVERY TIME an incremental is run, even
though THE DATA HAS NOT CHANGED.
We have converted over 200 NT desktops to WIn2K PRO. For each of our Win2K
PRO systems, this adds 1586 files to the backup every night.
This has had an enormous impact on the TSM server. The additional data is
only about 20 GB per night, and that's not a big problem. But each of the
SYSTEM FILES still has it's own entry in the TSM data base.
You do the math: That's over 300,000 additional objects that get added AND
deactivated each day, which for me means an additional 2.5 HOURS of EXPIRE
INVENTORY time is needed DAILY. And all for data THAT HAS NOT CHANGED.
TSM's strength has always been that it DOESN"T back up unchanged data.
Well, at least it didn't used to...
My problem here is we have another 250 machines to convert from NT to WIn2K.
They aren't about to buy me a second TSM server to handle the load, when the
current one worked fine for backing up the same number of NT systems with
the same amount of user data. Instead they are looking at some Windows-only
software to back up the WIndows side of the house.
It appears to me the current TSM implementation is flawed, and will inhibit
other people's ability to support large Windows environments as well as
ours.
I put this information into the Requirements for the Oxford Symposium,
hopefully it will give some additional visibility to the issue.
Any suggestions welcome ....but don't suggest we give up our ability to do
full bare-metal restores.
Management will change the backup software first.
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
[EMAIL PROTECTED]
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
