> I hate the way a backup is deemed "failed" because
> 1 or 2 files don't back up...  I was told this was
> a feature ...

Whoever told you this is wrong. The failure to back up
an individual file during incremental backup should not
result in a failed backup. In and of itself, skipped
files should not cause the event to show as "Failed" when
you use the QUERY EVENT command.

With that said, there was a bug (APAR IC31844) in the
4.2.1.0 client that did cause backups to show as failed
for skipped files. You say you are running the 4.2.0
client, but that bug was not present in 4.2.0. Are you
sure you aren't running 4.2.1.0, or that the backup isn't
failing for some other reason?

As for the simultaneous write to the copy storage pool:
I am not an expert on that part of the product, but the
failure should apply only to the session in question,
not all backups for all clients. Have a look at the
COPYCONTINUE option for the DEFINE STGPOOL or UPDATE
STGPOOL command, as I suspect that might address the
issue you are seeing.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED] (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.




"jane.bamberger" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
01/24/2003 07:15
Please respond to "ADSM: Dist Stor Manager"


        To:     [EMAIL PROTECTED]
        cc:
        Subject:        Trying new option to simultaneously write to backup and 
offsite copy  pool



Hi,

Last night I tried to use the new feature allowing me to copy to an
offsite copy pool at the same time I did backups. One of my servers had 2
files fail to backup - and this caused my offsite copy to fail. Does
anyone know why this is true?

I hate the way a backup is deemed "failed" because 1 or 2 files don't back
up...  I was told this was a feature - but if it causes this behavior in
the copy pool process- it is not a very good one.

AIX 4.3.3
TSM 5.1.6.0
TSM 4.2.0 - AIX Client

01/23/03 22:34:06     ANR0406I Session 4350 started for node RXSRVR (AIX)

                       (Tcp/Ip 10.1.128.19(51506)).
01/24/03 02:21:34     ANE4005E (Session: 4350, Node: RXSRVR)  Error
processing
                       '/var/adm/SPlogs/filec/sup01.22.2003.23.10': file
not
                       found
01/24/03 02:21:36     ANE4005E (Session: 4350, Node: RXSRVR)  Error
processing
                       '/var/adm/SPlogs/filec/sup01.22.2003.23.10r': file
not
                       found
01/24/03 02:21:58     ANR4734W Copy storage pool OFFSITE_COPY was removed
from
                       the copy storage pool list because of a failure for

                       session 4350.
01/24/03 02:24:19     ANR0403I Session 4350 ended for node RXSRVR (AIX).

I'd appreciate any help.

Jane
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Jane Bamberger
IS Department
Bassett Healthcare
607-547-4784

Reply via email to