There isn't any consistent, accurate way to have the TSM server track the
status of events that run outside of the TSM scheduler. In general, if you
use external scheduling facilities, it is assumed that you are also going
to track the results (that's not really so much by design, but just how it
happens to work). However, we fully understand the need to have a more
centralized reporting mechanism, regardless of how the event is scheduled,
and we working on improvements in this area.. For now, though, neither the
SUMMARY table nor the accounting log will give you an accurate completion
status. If you move to the 5.1 client levels, you can use the return codes
from dsmc to gauge success or failure of the event.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Andrea Campi <a.campi AT INET DOT IT>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/29/2003 01:58
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Is the BACKUP_START columns reliable?
On Mon, Apr 28, 2003 at 10:57:41AM -0700, Andrew Raibeck wrote:
> As far as I know, a backup that runs successfully but end up not backing
> up anything, and otherwise doesn't run into any problems, should not
cause
> the SUMMARY table record to show as unsuccessful. Something else may be
> going wrong, but there is not enough information for me to offer an
> opinion.
Uhm sorry, I was wrong. In fact, no row at all appears in SUMMARY about
that session - which is even worse in a sense.
> With that said, I do not recommend using the SUCCESSFUL flag in the
> SUMMARY table as an indicator of success. See discussion on "Query Event
> VS Successful Flag" from earlier this month at
> http://my.adsm.org/adsm-l.php or http://search.adsm.org.
Yes, I'm familiar with this thread. However, QUERY EVENT is not an option
here, as (for reasons I can explain if you want, but would a different
lenghty thread) I don't schedule backups from Tivoli, but let each client
schedule it via crontab.
So the only other option is dsmaccnt.log, which has (or at least had) its
own set of problems. In fact I've tried to merge the two sources of
information,
and found out there are sessions missing from one that the other has, and
vice versa. Sorry I don't have hard facts at hand right now; but if you
are interested and think that infos I might provide could be useful,
I'll gather more info (next week).
Thanks for your responsiveness.
Bye,
Andrea
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
>
>
>
> Andrea Campi <a.campi AT INET DOT IT>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 04/28/2003 09:48
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re: Is the BACKUP_START columns reliable?
>
>
>
> On Mon, Apr 28, 2003 at 07:11:34AM -0700, Andrew Raibeck wrote:
> > 1) Is this an incremental backup of the entire file system, or just
> > portions of the file system? If just portions, then the file space as
a
> > whole is not considered backed up. This could explain what you are
> seeing.
> > Is the user backing up individual files or directories? Or is there
some
>
> Good catch, that was it.
>
> Just for the record: I instructed the client to user virtualmountpoints
> instead, and everything appears to be working.
>
>
> Oh and by the way. The same client has another issue: if no file
> on any filesystem has changed, the backup is reported has having
> saved zero bytes (which is fine), and the final status as reported
> in the SUMMARY table is not successful. There was no error nor
> warning - it's just that no data was transferred. Is this by design,
> can it be fixed, or is there any workaround (other than relying on
> dsmaccnt.log)?
>
>
> Bye,
> Andrea
>
> --
> Andrea Campi mailto:a.campi AT inet DOT it
> I.NET S.p.A. - BT Ignite http://www.inet.it
> Technical Dept. - R&D phone: +39 02 32863 ext 1
> v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705
> Settimo Milanese (MI), Italy
--
Andrea Campi mailto:a.campi AT inet DOT it
I.NET S.p.A. - BT Ignite http://www.inet.it
Technical Dept. - R&D phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy
|
