%BACKUP-E-READATTR error - need some guidance

[Neil Ashworth_1]

Hi, we had this error in last nights backup, and not sure how much of an error this is:

%BACKUP-E-READATTR, error reading attributes for DSA703:[APPLICATION]APPFILE.DAT;2
-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-READATTRRETRY, 2 READATTR errors occurred reading DSA703:[APPLICATION]APPFILE.DAT;2

The file is there as I can do a dir/full on it, and anal/disk is clean. Unfortunately the file is in use, so cannot do anal/rms.

OpenVMS 7.3-2 on AlphaServer GS1280 with patch kit BACKUP V4 installed.

What do you think - is the file corrupt?

[Kris Clippeleyr · Accepted solution]

Neil,

From the release notes of a patchkit for BACKUP, we can learn.


BACKUP attempts recovery (retry) from a READATTR error, when a "no such file" error is returned from the XQP when reading an extension header, with open, fragmented files (/IGN=INTERLOCK is used).

The fix is to retry the same extension header 3 times. If any of those access attempts are successful, continue to move forward through the file while logging the number of attempts. If the retry count is exhausted the file is no longer considered a target and the READATTR/NOSUCHFILE error will be reported. A new message has been added that reports the retry count.

Following are a few examples of possible message sequences:

o Success example 1: Recovered from the first and only error.

%BACKUP-W-READATTRRETRY, 1 READATTR error occurred reading $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1

o Success example 2: 17 retries to save the file, though it was saved successfully.

%BACKUP-W-READATTRRETRY, 17 READATTR errors occurred reading $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1

o Failure, example 1: A failing sequence where no successful retries occurred before eventually failing on the same extheader 3 times.

%BACKUP-E-READATTR, error reading attributes for $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1
-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-READATTRRETRY, 1 READATTR error occurred reading $4$DKA310:[READATTR]1XQPXR_FRAGMENT.DAT;1

o Failure Example 2: A failing sequence of 3 successful retries while moving forward through the file on different EXTHDRS, but eventually, unable to recover from the fourth READATTR detected.

%BACKUP-E-READATTR, error reading attributes for $4$DKA310:[READATTR]2XQPXR_FRAGMENT.DAT;1
-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-READATTRRETRY, 4 READATTR errors occurred reading $4$DKA310:[READATTR]2XQPXR_FRAGMENT.DAT;1

The larger th size, more fragmented and interactive the open file, the lesser the chance of success. Use of /IGNORE=INTERLOCK implies open files are to be processed. If messages for files are paired (both READATTR/READATTRRETRY are reported) then the file did not get saved completely. Success is a READATTRRETRY message only.


So, to summarize, that file has extensions, is probably open, and could not be completely saved by BACKUP.
If the data in the file is important to you (and/or tgo your customers), make sure the file is closed before taking the backup; /IGNORE=INTERLOCK is not such a good idea, since it (might) result(s) in corrupt data on the backup medium.

Regards,
Kris (aka Qkcl)

[Upstate Rob]

I doubt the file is corrupt, but until you close it, you know nothing. Make a backup (or even a backup copy of the file) when it is not being used in any way. I think you will have no problem doing that (and then backing up the COPY of the file to tape, not the always-in-use original). Then, as a test, restore that COPY (rename the real one) and start the users up again and see if all is well. Open files, especially Databases, cannot truly be backed up while in use ... period. It is not the status of the original file that is in danger, it is the status of the backup you get (as noted by the previous reply).

[Jan van den Ende]

Neil,

Except for closing the file (not always an option) the ONLY way to get CONSISTENT info in your backup is to do a
$ CONVERT/SHARE to a backup version of the file just before the actual BACKUP.
After restoring the backup, rebuild your actual file from that. (CONV/FDL, or simple COPY or RENAME for sequential files).

hth,

Proost.

Have one on me.

jpe