I agree. It takes a good bit of Manual checking to MAKE SURE stuff is being
backed up. Querying events on server is not good enough. I have had them show
as completed/successful when in fact clinet backed up NOTHING, and there was no
dsm.opt or backup.excl to exclude it. Using CMD for one can cause this, where
the CMD runs on say an NT box and doesn't complete or actually run backup but
it does not cause a RC of other than 0.
One way is to q actlog looking for mesgno that gives summaries such as number
of objects backed up or Amount of data backed up. This is better but it
doesn't work for some DB backups (like Oracle with EBU or RMAN).
Basically I use the Q events and q actlog and look a system that had a problem.
Then for a new system or one that has had a problem I will do a detailed check
of dsmerror.log or dsmsched.log for at least several days to make sure it is
o.k.
Then I will just do a "random sampling of clients" some days to examine
dsm*.log to make sure it is working o.k.
I think I would need some serious script writing and integration or pay some
big price for some existing package (if it exists) to really "make sure" that
everyting is being backed up.
My 2 cents.
David Longo
>>> ADSM AT MAINE DOT EDU 06/13/01 10:35AM >>>
Richard supplied a great "horse before the cart" post, but I think there is
substantial merit in the notion of "verification of backups", especially if
this means "enhancing the chance for rapid and complete restores, without
surprise, to meet operational objectives".
*SM, by itself, is inadequate to ensure "verification of backups", IMHO.
I'm reminded of incidents with three of my clients in my early days with
ADSM.
A Netware administrator approached me asking if his backups were up-to-
date. I looked (on the backup server) at his file systems and saw each was
recently backed up without error. I responded "Yes!". I was wrong. The
Netware administrator had just experienced a disk crash and couldn't
restore the file system. It hadn't been backed up. His predecessor had
coded a DOMAIN statement in DSM.OPT (necessary at the time to stop backup
of file systems that shouldn't be backed up) and when a new disk and file
system was added, the DSM.OPT file was not adjusted.
A Windows desktop client approached me with help in restoring his PIM's
data base file. He'd received my weekly automatic e-mail suggesting that
his file systems were backed up successfully, but couldn't find his PIM's
data base file for restore. It wasn't backed up. He had not viewed his
DSMSCHED.LOG file since installing his PIM, else he would have seen that
ADSM could not read his PIM data base file, since the PIM had an exclusive
lock on it. A single file failure was not part of what I could then see at
the backup server.
Another desktop client approached me asking why he couldn't restore a file
that was on his machine the previous week, but inadvertently erased. The
reason was that he had decided to conserve power and turn his machine off
each night (during his backup window!). My weekly e-mail reminder would
have pointed out the problem, but it wouldn't be generated until the next
day ... not that it would have helped: he filtered it into a folder that he
rarely viewed.
So, I very much prefer and encourage "user verification of backups". The
user (the *SM client) often have an understanding of the importance of
their data. *SM information at the backup server to "verify backups" has
increased over time, but wrt verification of backups, I am merely a
supporter, as the "buck stops here" at the data owner (*SM client user).
Hope this helps,
Wayne T. Smith ADSM AT Maine DOT edu
ADSM Technical Coordinator - UNET University of Maine System
"MMS <health-first.org>" made the following
annotations on 06/13/01 10:57:43
------------------------------------------------------------------------------
---
This message is for the named person's use only. It may contain This message
is for the named person's use only. It may contain confidential, proprietary,
or legally privileged information. No confidentiality or privilege is waived
or lost by any mistransmission. If you receive this message in error, please
immediately delete it and all copies of it from your system, destroy any hard
copies of it, and notify the sender. You must not, directly or indirectly,
use, disclose, distribute, print, or copy any part of this message if you are
not the intended recipient. Health First reserves the right to monitor all
e-mail communications through its networks. Any views or opinions expressed in
this message are solely those of the individual sender, except (1) where the
message states such views or opinions are on behalf of a particular entity;
and (2) the sender is authorized by the entity to give such views or opinions.
==============================================================================
|
