Well, Tim's right, IMHO: there ought to be an easy (automatic, in fact) way
to:
find missed schedules
find missed files
report them to the right people
Some techniques we used in building Servergraph/TSM are:
1. Prevention: catch TSM's "I can't connect to client X" messages in the
activity log at 8:00 PM or whenever a schedule starts, and immediately
forward them to an operator. If the operator will then restart the
scheduler, or fix the network problem, or whatever, then you will have a
completed backup in the morning instead of a missed backup.
2. Enlist the users: for large sites, we tie an email address to each
node,
and send a canned message to that address that explains how to restart the
scheduler. So the users can do some of the obvious things for you. Of
course this won't work for all sites - some users prefer to be oblivious -
but you can always put in the help-desk address.
3. Use filespace dates: We agree that "q event" is not totally
reliable, so
we suggest "query filespace f=d", and look at the last backed-up date. This
also shows you filespace that you should delete - i.e., the one named
client_X/mnt, not backed up in 2 years. Somebody left a CD-ROM mounted 2
years ago; TSM backed it up and is religiously saving that useless space.
4. Sort nodes by how many missed files they have. So over time, you can
either fix your excludes or learn to shut down databases before backing them
up, and the number of missed files goes toward zero.
The fact that TSM will report a backup complete even though it misses a few
files is a problem, I think. My desktop PC typically misses only one file:
outlook.pst, 120 MB of email that *I* consider *VERY* important - but that
backup is marked "completed"!
So if you REALLY want to be sure, you HAVE to look at every missed file.
---------------------------------
Mr. Lindsay Morris
Mr. Lindsay Morris
CEO, Servergraph
www.servergraph.com
859-253-8000 ofc
425-988-8478 fax
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Jim Healy
> Sent: Wednesday, April 17, 2002 8:43 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Daily Backup Report
>
>
> The cheapest way to do this is to get yourself familiar with SQL queries,
> all the information you need is in the tables.
>
>
>
>
> "Mark Bertrand" <Mark.Bertrand AT USUNWIRED DOT COM>@VM.MARIST.EDU> on
> 04/16/2002
> 03:56:30 PM
>
> Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
>
> Subject: Re: Daily Backup Report
>
>
> So, if I follow your message correctly and the point I have been trying to
> make... There is no easy (one button) method of reporting, which should be
> the basis of the software, the very basic core of any backup
> software, that
> I don't have.
>
> To answer the other question posted by Mr. Joseph Dawes, How do I track
> failures?, I do it the long way. I start with the q events ex=yes as a
> first
> level then we start going through the activity logs starting with a search
> for ANE4959i reporting missed files. Next we go through individual error
> logs on the clients if necessary.
>
>
> -----Original Message-----
> From: Rushforth, Tim [mailto:TRushfor AT CITY.WINNIPEG.MB DOT CA]
> Sent: Tuesday, April 16, 2002 1:05 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Daily Backup Report
>
>
> And it depends on what you mean by a "successful" backup...
>
> We use Bill's method below to report on all events taht do not have a
> status
> of completed. (We only used to report on exceptions also ...)
>
> If you are worried about some files that were not processed then
> "completed"
> does not tell you what you want (for incrementals on 4.x clients and
> below).
> Here you will have to do additional queries to report on these failed
> objects. With archives and selective backups however, files in use will
> report as failed (can't confirm if other failed files will) (again 4.x and
> below) so that is covered here.
>
> Now, with 5.1, incrementals, archives, and selectives all report
> "completed"
> if files are not processed because of some error.
>
> But with incrementals you can now check the return code: 4 = files skipped
> (doesn't count files excluded by exclude statements). But with selectives
> and archives rc=4 could simply mean that your exclude statements are
> working
> so now you will have to do additional queries to report on failed objects
> here.
>
> We also do queries on file spaces as was mentioned that reports when the
> last backup completed. We've had at least one occasion where security was
> changed on an NT drive so that the "System Account" no longer had access
> (that is what the TSM scheduler was using). Here the backup status showes
> "completed" but the filespace in question did not get backed up and the
> file
> space query picked it up.
>
> Tim Rushforth
> City of Winnipeg
>
> -----Original Message-----
> From: Bill Boyer [mailto:bill.boyer AT VERIZON DOT NET]
> Sent: Tuesday, April 16, 2002 9:40 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Daily Backup Report
>
>
> Be very carefull with the EX=YES. There is a status of an event of '(?)'
> that doesn't show as an exception. This condition can occur when a backup
> schedule starts for a node, and then due to either the client
> crashing or a
> networking issue the connection is dropped and never re-established within
> the DURATION of the event. The status is '(?)'. There is an APAR open to
> have meaningful status's instead of the '(?)', but for now this doesn't
> show
> as an EXCEPTION.
>
> We got bit big-time at a client of our where they out-sourced the entire
> TSM
> operation to us. They were having failures, but they were not showing on
> our
> EX=YES report. They were not happy campers! I'm still having a hard time
> sitting! :-)
>
> We ended up writing some PERL code to parse the Q EV client events and
> reporting on anything that isn't COMPLETED.
>
> This behavior started somewhere in the 4.1.x patch levels. So, just be
> careful relying on the EX=YES to give you everything that failed.
>
> Bill Boyer
> DSS, Inc.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Williams, Tim P {PBSG}
> Sent: Tuesday, April 16, 2002 10:01 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Daily Backup Report
>
>
> we generally run a q event command ex=yes
> you can use begindate begintime parms, etc....
> help q event
> fYI
>
> -----Original Message-----
> From: Orin Rehorst [mailto:rehorst AT POHA DOT COM]
> Sent: Tuesday, April 16, 2002 8:48 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Daily Backup Report
>
>
> What are some good ways to get an automated daily report on which clients
> were or were no backed up successfully?
>
> TIA,
>
> Regards,
> Orin
>
> Orin Rehorst
> Port of Houston Authority
> (Largest U.S. port in foreign tonnage)
> e-mail: rehorst AT poha DOT com <mailto:rehorst AT poha DOT com>
> Phone: (713)670-2443
> Fax: (713)670-2457
> TOPAS web site: <www.homestead.com/topas/topas.html
> <http://www.homestead.com/topas/topas.html> >
>
|
