- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: %BACKUP-E-READATTR error - need some guidance
Operating System - OpenVMS
1755654
Members
2915
Online
108837
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-01-2005 04:58 AM
тАО12-01-2005 04:58 AM
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?
%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?
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-01-2005 06:28 AM
тАО12-01-2005 06:28 AM
Solution
Neil,
From the release notes of a patchkit for BACKUP, we can learn.
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)
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)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-28-2005 06:32 AM
тАО12-28-2005 06:32 AM
Re: %BACKUP-E-READATTR error - need some guidance
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).
Another Simple Solution to a Complex Problem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-28-2005 09:30 PM
тАО12-28-2005 09:30 PM
Re: %BACKUP-E-READATTR error - need some guidance
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
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
Don't rust yours pelled jacker to fine doll missed aches.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP