Re: Is the BACKUP_START columns reliable?

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.

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.

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