Well... actually, if you really want to do it (I would consider it), you can
exclude System Object (or, better, use a "special" management class which
maps to a copygroup that has FREQuency=5, so INCRemental backups only occur
every 5 days).
Clearly, the 200-400MB blob called System Objects, Microsoft wants the whole
set (or none) in the event of system recovery; that's why you always get all
the system files & DLLs, etc. If you use the 5.1 client, test to make sure
you get the desired results; exclude or avoid backup for System Object on a
daily basis is reasonable -- you must weigh the value of not having it
backed up as often as you did for NT... many shops make system level
recovery images daily, others do it weekly (some even bi-weekly or
monthly) -- which makes you vulnerable to corruption with restore data
that's more than a day (or week) old, so you may lose some config changes
that didn't get backed up.
Actually, my personal favorite, is to use the NT backup tool (maybe as a
preschedcmd) for making the System Object backup (to a file that gets picked
up by normal, daily incremental); in the cmd file that runs NTbackup,
determine the daily or weekly logic of your choice, so only re-write the
SysObj.bkf as often as you like... possibly, every Tuesday & Saturday,
whatever. So, with the 5.1 client, exclude system object backups -- relying
entirely on recovery of the ntbackup file to recover the system, which gives
the nice side-effect of providing a point-in-time recovery point and (also)
allows authoritative restore (of selected pieces of the registry, using
directory services restore mode). This "side effect" becomes important if
ever you want to use the "authoritative restore" feature introduced by
Win2K; the current method of backups provided by TSM only permits
non-authoritative restores.
Don France
Technical Architect -- Tivoli Certified Consultant
Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
San Jose, Ca
(408) 257-3037
mailto:don_france AT ayett DOT net (change aye to a to reply)
Professional Association of Contract Employees
(P.A.C.E. -- www.pacepros.com)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Lawson, Jerry W (ETSD, IT)
Sent: Wednesday, October 16, 2002 6:48 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: More on Repeat Backups...
Date: October 16, 2002 Time: 7:31 AM
From: Jerry Lawson
The Hartford Insurance Group
860 547-2960 jlawson AT thehartford DOT com
----------------------------------------------------------------------------
-
First - let me thank you all for the responses to my original question.
Your answers have gotten me thinking some - I say some, because at my age,
it's hard to get everything going again, and I suffer from "senior moments"
too often.
Most of the answers revolved around the suggestion that I could exclude
something - either the files themselves, or the System Object itself if I
get the newest client. This seems to me to be treating the symptom, rather
than the problem - if I exclude them, obviously, I can never restore them
(DUH!). If these do get corrupted or deleted, it would appear that I could
be in for another bout with my desktop support folks - they just had my
Laptop for 3 weeks - I'm not eager to deal with them again. Now I will be
the first to admit that I'm not MS Certified on any OS, and so the idea of
excluding the whole System Object is scary as well - doesn't that include a
big portion of registry information if I need to do a complete restore? Or
is the idea of a Bare Metal restore with TSM one that has died?
In my (sometimes overly simplistic) mind, I remember the ADSM class I
attended where the instructor identified how a file was determined to have
changed - either the date, the time, or the size has changed. Has TSM
changed this philosophy? After all, I look at the files in question, and
nothing has changed that I can see externally. Shouldn't there be a better
approach than to say "well, they're a part of the system object, and
therefore you need to exclude them." Shouldn't the software be smart enough
to figure this out?
----------------------------------------------------------------------------
-
Jerry (still tilting at
windmills)
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.
|
