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
|
