Hi Bill,
Here's what I know so far:
These files are defined to be part of "Win2K system protected files". (This
is actually explained pretty well in the 3.7/4.1 Tech Guide Redbook;
additional info in the 4.1.2 Win client Redbook.) They are cataloged as
such by Win2K (I don't know for sure but I think it has to do with the
CATROOT directories in system32/config) and have some sort of hash code or
signature that identifies them as being "good". These files get copied into
the dllcache directory.
When you boot, Win2K somehow checks the signature of all the .dll, .exe, and
.obj files to see if they are still "good". If one of them has been
tampered with, Win2K refreshes your copy from the dllcache copy. This is
supposed to provide protection against the classic Win95 problem where
downloading and installing a software upgrade changes the wrong .dll and
stuff doesn't match anymore, resulting in the Blue Screen of Death.
All well and good, works for me.
Now Microsoft says that these "system protected files" (including the boot
files), the Registry, the Active Directory (for servers), and the other
components of "SYSTEM OBJECT" should all be backed up and restored as a set.
I.E., you shouldn't restore the registry without restoring the system files,
and vice versa. And you aren't supposed to restore individual .dll files;
it's all or nothing.
So I can see that TSM needs to support that, and I can support that. I just
question the current TSM implementation.
I have thought about limiting the SYSTEM OBJECT backup, as you have done,
but MANY of the restores we do here include the registry, and I assume you
can get into trouble if your copy of the registry is not taken at the same
time as the SYSTEM FILES, which include that "catalog" of "good" SYSTEM
FILES. (In fact, the 4.1.2 Win client redbook says you MUST run QUERY
SYSTEMOBJECT and check to make sure your SYSTEM FILES and REGISTRY were
backed up at the same time before trying to restore - how vital that is, I'm
not sure.)
The practical differences in backing these files up as part of the C: drive
backup vs. backing them up as part of "SYSTEM OBJECT", are that 1) backing
them up as part of SYSTEM OBJECT backs them up whether they have changed or
not, and 2) Microsoft says you aren't supposed to restore these files
individually anymore.
Again, my problem is with WAY TSM has implemented this. If you backup the
SYSTEM OBJECT, you can't restore the files individually. But if you run:
SELECT * FROM BACKUPS WHERE FILESPACE_NAME='SYSTEM OBJECT'
you can see all the cazillion entries for all those individual objects. You
can also see each file processed individually in dsmsched.log. So it
APPEARS we are taking the overhead of backing them up individually, without
getting any of the benefits of restoring them individually.
Seems to me if you can only restore them as a set, the proper implementation
would be to have ONE data base entry describing the set, and any other
necessary descriptions of individual objects that are part fo the set should
be stored INSIDE the set itself, not in the data base.
But much of this is speculation on my part. All I have to go by is the
information in the TEch Guide redbook, what I see, and the fact that I have
a problem since we implemented SYSTEM OBJECT backups.
Thanks for the input...
Wanda
-----Original Message-----
From: Bill Colwell [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 01, 2001 4:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Issues with Win2K SYSTEM OBJECT/SYSTEM FILES backup
Wanda, thanks for the info.
I was aware of this feature so I am staying on 4.1.1.16 where 'system
objects'
is not in the default domain. For each w2k machine I make an additional
schedule to back up 'system objects' every 4 weeks.
I wonder what is the difference between backing up these files thru the
normal
backup of the C drive and backing them up as part of 'system objects'. Put
another way, what necessary data or meta-data is added by using the system
objects
path. This is probably more a question about the win2k system than about
tsm.
--
--------------------------
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
[EMAIL PROTECTED]
--------------------------
In <[EMAIL PROTECTED]>, on 06/01/01
at 04:56 PM, "Prather, Wanda" <[EMAIL PROTECTED]> said:
>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
>************************************************************************
