Hi,

If you implemeted copy stg pools the "audit vol fix=yes" will only mark the
damaged files as damaged in the database. The restore vol will copy the
damaged files from copy stg pool volumes back into the primary pools and the
volume that countained the damaged files will be returned to scratch if this
were the last objects still on that volume. Then the back up stg pool will
run as planned.

Only do a delete volume when restoring and moving is inpossible.

Regards,

Karel

-----Oorspronkelijk bericht-----
Van: David Soucy [mailto:dsoucy AT DIGITAS DOT COM]
Verzonden: dinsdag 6 april 2004 0:20
Aan: ADSM-L AT VM.MARIST DOT EDU
Onderwerp: Get rid of damaged files?


After migrating our entire datastore from DLT to LTO2, I have discovered
a bunch of damaged files that did not migrate to their new storage pool
cleanly. (It's possible they may have been damaged already)

I started getting these errors, which I'd never seen before:

ANR1330E The server has detected possible corruption in an object being
restored or moved. The actual values for the incorrect frame are: magic
53454652 hdr version 0002 hdr length  0032 sequence number 00000003 data
length 0003FFE0 server id 00000000 segment id 0000000061393938 crc
00000000.
ANR1331E Invalid frame detected.  Expected magic 53454652 sequence
number 00000003 server id 00000000 segment id 0000000061459474.

So I started doing some 'audit vol xxx FIX=YES' on the volumes that were
mounted at the time I was getting these errors and then retrying the
'backup stg' operation again.  This cleared up all but one of the
ANR1330E and ANR1331E errors.  Now it just skips the files and continues
on.

I get the ANR1330E and ANR1331E only once, on a volume that I've audited
at least two or three times with the FIX=YES option.  It seems to me
that there's a file that can't be fixed, or even identified.

What's going on here?  I probably don't care about that file either,
can't I just delete it somehow?

-ds