ADSM-L

Re: reporting on backup successes/failures

2002-04-08 16:27:02
Subject: Re: reporting on backup successes/failures
From: "Mr. Lindsay Morris" <lmorris AT SERVERGRAPH DOT COM>
Date: Mon, 8 Apr 2002 16:27:02 -0400
I guess they do compression or something -
I see one yesterday that reports 125 MB backed up by the ANE4991 message,
but the TSM server's accounting log message says only 65 MB.

---------------------------------
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
> Remeta, Mark
> Sent: Monday, April 08, 2002 9:48 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: reporting on backup successes/failures
>
>
> Well the q event, like the level 2 tech mentioned, only reports on whether
> the batch command started successfully, not on whether the actual tdp
> commands within the batch were successful. If it is tdp for
> exchange you are
> trying to monitor, you may want to try and do a 'q act begint=whenever
> msg=4991'. This will show you when the tdp sessions start and end and also
> how much data was backed up. Ps: change the whenever to whatever time you
> want to start looking from, I usually put 00:00 to start from midnight.
>
> Mark
>
>
> -----Original Message-----
> From: Mark Bertrand [mailto:Mark.Bertrand AT USUNWIRED DOT COM]
> Sent: Monday, April 08, 2002 9:03 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: reporting on backup successes/failures
>
>
> Let me begin by saying that this rant is in no way meant to be directed to
> Mark Stapleton, his advice has helped me many times and he is a
> great asset
> to the group, he never hesitates to help.
>
> Be aware, q event ONLY reports on the success or failure of the backup
> script being ran, NOT the actual job.
>
> Example: Last week the below method was used as it is everyday to
> check the
> status of scheduled jobs and it reported the following.
>
> 04/05/2002 01:30:00 04/05/2002 02:01:54 130AM_EXCHANGE03_DB- EXCHANGE03_DB
> Completed
>
> But.... when you actually look into the job you still see it running as a
> session.
>
> Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name Number Method
> State Time Sent Recvd Type ------ ------ ------ ------ -------
> ------- -----
> -------- -------------------- 3,102 Tcp/Ip RecvW 0 S 8.0 K 11.6 G Node TDP
> EXCHANGE03_DB MSExc- hgV2 NT
>
> And the activity log only shows that the Directory completed, the
> Information Store is still being backed up.
>
> I spoke to level 2 support and I understand that q event only
> reports on the
> script, he suggested that I need to put some kind of wait statement in the
> script to not let it complete until the job actually completes.
>
> I am not very happy with his suggestion, I am querying the event, I am not
> running a q script!!! I don't want a Band-Aid, I just want a q event that
> works!!!
>
> Is there another solution within Tivoli to query the actual events?
>
> BTW, we are running TSM 4.1.3 on W2K server and the example is
> for Exchange
> TDP 2.2 on Exchange 5.5.
>
> Thanks all,
> Mark B.
>
> -----Original Message-----
> From: Mark Stapleton [mailto:stapleto AT BERBEE DOT COM]
> Sent: Sunday, April 07, 2002 10:39 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: reporting on backup successes/failures
>
>
> On Tue, 5 Mar 2002 10:26:18 -0600, "Glass, Peter"
> <Peter.K.Glass AT WELLSFARGO DOT COM> wrote:
>
> >What would be the best way to produce a report that shows the number of
> >client backup successes vs. failures, for a given day?
>
> This is not as hard as some folks seem to want to make it:
>
>   q event * * begind=<start_date> endd=<end_date>
>
> If you want it in script form:
>
>   def script backup_check 'q event * * $1 $2 > /tmp/backup_check'
>
> You run it by inputting
>
>   run backup_check 04/01/2002 04/03/2002
>
> --
> Mark Stapleton (stapleton AT berbee DOT com)
>
> Confidentiality Note: The information transmitted is intended only for the
> person or entity to whom or which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of this information by persons or
> entities other
> than the intended recipient is prohibited. If you receive this in error,
> please delete this material immediately.
>