ana/rms returning errors on a file after the restore from backup.

[allin-in-one]

Hi,

We have a backup application. After restoring a indexed file from backup of  ana/rms returning errors.

***  VBN 4:  Record at offset %X'0291' has a missing or illegal RRV.

***  VBN 4:  Record at offset %X'029A' has a missing or illegal RRV.

***  VBN 4:  Record at offset %X'02D0' has a missing or illegal RRV.

***  VBN 41:  Record at offset %X'01E1' has a missing or illegal RRV.

***  VBN 41:  Record at offset %X'01EA' has a missing or illegal RRV.

***  VBN 41:  Record at offset %X'01F3' has a missing or illegal RRV.

***  VBN 41:  Record at offset %X'01FC' has a missing or illegal RRV.

***  VBN 190:  Record at offset %X'000E' has invalid data key compression.

***  VBN 41:  Record at offset %X'0217' has a missing or illegal RRV.

***  VBN 190:  Record at offset %X'000E' has invalid data key compression.

***  VBN 41:  Record at offset %X'0220' has a missing or illegal RRV.

***  VBN 190:  Record at offset %X'000E' has invalid data key compression.

***  VBN 100:  Record at offset %X'0259' has a missing or illegal RRV.

***  VBN 190:  Record at offset %X'000E' has invalid data key compression.

***  VBN 100:  Record at offset %X'0262' has a missing or illegal RRV.

***  VBN 190:  Bucket check byte is out of phase.

***  VBN 190:  Invalid key of reference in bucket header.

***  VBN 190:  Invalid bucket address sample in bucket header.

***  VBN 190:  Invalid first free byte offset in bucket header.

***  VBN 190:  Invalid level number in bucket header.

***  VBN 190:  VBN free space offset is invalid.

***  VBN 190:  Next-bucket pointer out of range of file.

Unrecoverable error encountered in structure of file.

The dump of the file before and after the restore not having any differences.

Also there are no differences in file attributes before backup and after the restore.

Please let me know what are the precautions I need to take for indexed file  while backup and restore ?

The problem is occuring for a particular indexed file only,other indexed files are ok. (i.e. no errors)

Reading and writing the file using sys$qio.

Thanks

[Steven Schweda]

> We have a backup application. [...]

   Not a very detailed description of anything.

> The dump of the file before and after the restore not having any differences.
> Also there are no differences in file attributes before backup and after
> the restore.

   If the data and the metadata really are all the same, then I would
expect the files to be equivalent.  Sadly, with my weak psychic powers,
I have no idea how you compared the files, so I have no idea if your
data and metadata really are all the same.

   As usual, showing actual commands with their actual output can be
more helpful than vague descriptions or interpretations.

   Does the VMS BACKUP program work properly on this file?

> Please let me know what are the precautions I need to take for indexed
> file  while backup and restore ?

   Reproduce the original data and metadata.  (The same as with any
other file type.)

> Reading and writing the file using sys$qio.

   I can't see your code, either.

   Again, Info-ZIP Zip and UnZip may have $QIO code which works.  If Zip
("zip -V") and UnZip can reproduce your file correctly, then you may be
able to learn something from those (open-source) programs.  If Zip and
UnZip fail to reproduce your file correctly, then the Info-ZIP folks
would be interested in a useful bug report (that is, a bug report

(unlike this one) which includes enough information to allow debugging
-- ideally, a small test case).

      http://info-zip.org/

[MarkOfAus]

Does this help?

http://unix.derkeiler.com/Newsgroups/comp.os.vms/2006-08/msg00118.html

[Volker Halle]

Hi,

if you dump the reported VBNs (DUMP/BL=(START:n,COUNT:bucket-size) from both the original and the restored file and do a DIFFERENCES on those dump output files, are all the bytes REALLY THE SAME ?

Volker.

[John McL]

Questions:

1 - Did you run BACKUP/VERIFY?

This will really check if the Backup was written correctly, but also see point 6 below because an open file could easily have a corrupt backup.

2 - Did you restore to the same system or to one running a different version of VMS or an upgraded Backup?

There might be small but important differences in the processing, such as difference defaults on the Backup command.

3 - Did you run Backup with compression but the restore operation without (or vice versa)?

I'd be surprised if you did but still somehow got the same attributes.

4 - What makes you believe that the file attributes are the same?  Please do DIR/FULL on both files and post that.

Maybe you just looked at the file size and the number of keys on the file ....

5 - Please do DUMP/BLOCK=(COUNT:0)/HEADER on both files and post that

This will provide even more attributes than the DIR/FULL.

6 - Did you run BACKUP/IGNORE=INTERLOCK and if so was that file open at the time? 

If so you would have risked writing a Backup where a file key had been updated but the record itself was yet to be written, or more common on large files that are frequently written to, had the problem that you save the index portion and after several transactions later (which altered both the indexing and the data records) save the data records, thus producing an inconsistent file. 

7 - Have you checked for device errors on that disk or shadow set?

[Steven Schweda]

> 1 - Did you run BACKUP/VERIFY?

   I know nothing, but I'd guess not.  If you look at previous postings
from this fellow, then you might conclude (as I have) that his "a backup
application" is _his_ "a backup application", not VMS BACKUP.  He's
never especially clear about this, and if you miss it, then your
suggestions tend to miss the mark.

> 5 - Please do DUMP/BLOCK=(COUNT:0)/HEADER on both files and post that
> [...]

   But that (like many other things which involve actual output from
actual commands) could be informative.

[abrsvc]

I will wait for comment from the original poster.  I would not conclude that "a backup application" means that VMS Backup was not used.  I have seen many locations refer to command procedures as "applications".

I do agree though, that there is an alarming lack of useful information as yet presented.

What is needed is at least:

1) The command(s) used to create and restore the file in question.

2) The DUMP/REC output as previously requested.

3) The DIR/FULL output as requested.

[Steven Schweda]

> [...] I would not conclude that "a backup application" means that VMS
> Backup was not used. [...]

  Other than those previous postings which I cited above, the telltale
clue (I claim) in this thread was:

> [...] Reading and writing the file using sys$qio.

   Most people who use VMS BACKUP neither know nor care how it does its
I/O.

[Hein van den Heuvel]

WAG... the 'tool' made a backup of a live file without synchronizing with RMS, catching it partialy updated.

That can happen with BACKUP/IGNORE=INTERLOCK, notable when DEFERRED WRITE is active.

I'm afraid I have to echo the sentiments of the prior replies.

Give us actuals, not vague descriptions.

>> The dump of the file before and after the restore not having any differences.

If there are not differences, then the original is also corrupt. Did you analyze that also?

How did you dump (/record? /block?)

How do you know what to look for for?

(If you really did, you'd be asking a much more articulate questions)

What tool did you use to determine differences

The OpenVMS DIFF tool will read RECORDS which might (unlikely though) not have been influenced but the structural issues **bleep**/RMS detected.

That file appears to the be a mess. At least the the first bits.

So you have to original?

Cool. Use it and move on. Case closed?

If that's now acceptable, use is to see what should have been there.

If you reply for more help, please provide the **bleep**/RMS/FDL/OUT=x.x output for the original file.

Also add DUMP/BLOCK=(STA=4,COUN=2) for BOTH original and restored,a nd BLOCK 190 to get going

Often a file does not change much in those first buckets, and those dumps may show what is different.

>> Please let me know what are the precautions I need to take for indexed file  while backup and restore ?

Shut down the application, or at least the writers.

OpenVMS does NOT make it easy to make backups of a live file, 

>> The problem is occuring for a particular indexed file only,other indexed files are ok. (i.e. no errors)

Is that particular file more heavily updated?

>> Reading and writing the file using sys$qio.

What the heck does that mean?

If you write an indexed file with SYS$QIO (instead of SYS$PUT) you are 'on your own'.

Cheers,

Hein

[allin-in-one]

Hi,

Thank you all for your suggestions/help. Sorry for the confusion created regarding the information provided by me.

We have a backup application and not using VMS BACKUP. Collected dump by running the command dump/out=filename inputfile. Unfortunately I could not provide FDL or any other output from problematic file here due to compliances.

Sorry for that.

Collected dump output (using the command “dump/out=filename inputfile”) for original file and restored file.

The diff of these files didn’t find any differences. The file is on a test system, hence no updates to this file.

Here I am trying to fix the problem with our backup application. The problem is occurring for one particular file only.

For all the other files after the restore didn’t report any errors for ANA/RMS.

Thanks