I think this should be important for all ADSM users. If a file on a tape gets
the "damaged"
attribute from any process (tape copy, reclamation,...) that file should be
backed up agin with
the next incremental.
The user of ADSM looks at his schedlog and all looks OK for him. This is really
a bad
bug in the design of ADSM. IBM should change this as  quick as possible.

Stephan Rittmann



++++++++++++++++++++++++++++++++++++++++++
I had once tried to convey this as a requested new feature, but I don't
think I explained it very well.  I have no idea what happened with it after
that point.

If the active copy of a file is damaged on the storage media, marked
damaged by an Audit Volume, the next incremental should back it up again,
then expire the bad copy.  The active copy of a file is just too important
to not have this done automatically.

Nick Cassimatis
nickpc AT us.ibm DOT com

If you don't have the time to do it right the first time, where will you
find the time to do it again?
++++++++++++++++++++++++++++++++++++++++++

Hi all,

at one of our NT ADSM servers I found 3 tapes with damaged files. I realised
it, bcause of WARNINGS in the backup STG process. This process only wrote into
the ACT LOG, that file xxx is damaged and will skipped for storge pool backup.

IBM told me that the damaged files wont be rebackuped with the next incremental
backup of the client. For me this is a really bad situation. The server knows
in his database that a specific file is damaged and does nothing else then
print a warning.  With a second backup this gap could be closed easily, or not?

Any comments?


Stephan Rittmann