Files-11 Home block not found

[Stinehelferw_1]

We have a corrupted data disk.
When attempting to mount we see an error stating there is no Files-11 home block.
I assume the INDEXF.SYS or another system file is corrupted. This disk has been used daily for a couple of months and has information we'd like to retrieve.

Does anyone have a method of fixing, not INIT a corrupted data disk?

Thanks!

[Volker Halle]

Hi,

welcome to the OpenVMS ITRC forum.

You should first create a backup copy with this disk with BACKUP/PHYSICAL.

Then you may want to try the DISKBLOCK utility from the current OpenVMS Freeware disk. You need to first find out and understand, what has happened to that disk and what the extent of the corruption is.

http://www.digiater.nl/openvms/freeware/v80/diskblock/

You need to know what you're doing when trying to diagnose and repair this - if it can be repaired at all. Understanding of the Files-11 ODS is required.

Volker.

[Hein van den Heuvel]

Just restore the backup!
Sorry, couldn't resist.

This would be the time to explain to management that some or all of the money they 'saved' by not having an adequate backup strategy may have to be invested now for an iffy recovery. And you want them to decide how much of your time can be burned in this mission, and/or how much monies might be made available pay someone to help you.

If you have a backup, but is is not recent enough, you may still want to roll it out to an other drive, the get a understanding what _should_ be there. You may find file ID's are useful to find back / recognize file headers.

Along the same lines, do you have a similar disk, either empty or in use? It is nice to be able to DUMP (logical) blocks from a known to be good disk to see what roughly should be there.

You first steps should be to MOUNT/FOR the bad drive and DUMP/BLOCK=(COUNT=1,START=xxx) probing the disk for data / recovery chance.
Just start with blocks 1, 10, 100, 1000, 10000, 1000000, 1000000
That wil give you an impression of how bad it is.

You are likely to need a Logical Block copy tool. And a Logical block SEARCH tool. DUMP + SEARCH might do, but a dedicated program my be needed. The goal is to find the file header(s) for any and all file which is worth recovering and use the mapping pointers in there to get to the data. Start looking for INDEXF.SYS, because if you can recover that, you are more than half way home... with some trickery.

You may have to hand craft a temporary indexf.sys to 'capture' file headers.

You may want to use a bound volume with a RAM or LD drive to map a reasonable structure to a bad structure, pointing to the file header on the bad disk.

Exploring what is left, with the understanding what should roughly be there, will be fun!

Good Luck,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting

[Jur van der Burg]

And then there's the salvage utility which may do the dirty work for you. Not open source I'm afraid, but HP can help you with that.

Jur.

[Robert Gezelter]

Stinehelferw,

First, I would recommend "Write locking" the disk immediately. It is very easy to do further damage.

A very good step at this point is one (preferably two for redundancy) BACKUP/PHYSICAL backups of the volume.

If you are familiar with the internals of FILES-11, then I would recommend examining the disk in hex to see what happened. If you are not, I recommend getting in touch with someone who is to examine the volume carefully (Disclosure: We provide services in this area, as do Hoff, Hein, and several other regular contributors to this forum).

I cannot emphasize the need for extreme caution. Data recovery can be an extremely delicate procedure, and it is easy to make things worse if one is not careful. It only takes a seemingly innocuous step to go from impaired to seriously damaged.

For that reason, it is always best to immediately archive the corrupted disk, and do all attempts at recovery on a cloned volume (one of the reasons for the BACKUP/PHYSICAL). If the clone is damaged, one can restart from the beginning. In fact, working on a clone is a MINIMAL practice for forensic analysis of mass storage, originals must be put on the shelf.

It is also important to document what was done, in the event that there later questions as to the accuracy and authenticity of the data.

- Bob Gezelter, http://www.rlgsc.com

[John McL]

Why do you say "when attempting to mount"? Does this mean that the disk is only mounted when required or were you rebooting the system?

On such important data I'm surprised that you don't have shadowing, or do you have it and are now attempting to mount the disk indoependently?

If my recollection is correct, only the primary volume of a volume set (i.e. more than one disk operating as if they were just one) has an INDEXF.SYS file. It would follow that if you are trying to mount a non-primary member of a (former?) volume set then you would not have that file.

What exactly was the configuration in which this disk was previously used?

[Hein van den Heuvel]

John wrote>> "if my recollection is correct, only the primary volume of a volume set (i.e. more than one disk operating as if they were just one) has an INDEXF.SYS file."

Sorry, that's NOT correct.
The primary volume has the real MAster / Root/ MFD / [000000] / [*] Directory.
That's where the searched will begin.
Other then that the structures are exactly the same.
Each directory entry has a file-id, file-sequence and file-relative-volume-number (rvn).
The RVN indicates which INDEXF.SYS to use.
The ID translates to a specific block in that INDEXF.SYS
The SEQ allows the system to sanity check.

fwiw,
Hein

[Robert Gezelter]

John McL,

With all due respect, your recollection concerning INDEXF.SYS is not correct.

A FILES-11 bound volume set consists of members, each of which is a valid FILES-11 volume. The "binding" sequence of the volumes is reflected in a single file (whose name and File ID I do not have offhand, since I am not near my in-house library at this instant).

The directory structure of a bound volume set is somewhat unusual, in that the references to the directories on the volume set as a whole start with a root of the MFD on the first volume, but the descendants are not required to be on the first volume, to the best of my recollection (without reference to the FILES-11 specification in my library).

- Bob Gezelter, http://www.rlgsc.com

[Stinehelferw_1]

This is a simple single data storage disk on which files are copied regularly to archive them.

Using DUMP/BLOCKS=(COUNT=10000,START=0) /OUT=DUMPFILE.TXT
I view was able to see that there are no blocks containing the names of files and directories for the disk.
Further, blocks 1-988 contain identical data and appear to be the home block and alternate home blocks. Why would there be so many alternate blocks?
These "alternate" blocks contain the volume name.
LBN0 has verbage stating it is not bootable, which is true. Its just a data disk.

I compared the disk to similar one using the same command and that one had blocks 1-70 identical and presume they are alternate home blocks. LBN71 contains directory names.

[Robert Gezelter]

Stinehelferw,

The precise layout of the disk is somewhat unpredictable, particularly on a disk that has been in use for an extended period with creations and deletions. If a defragmenter has been used things can become even more complex.

The default location for the INDEXF.SYS is the middle of the volume, but other values (including absolute starting positions) can be specified in the INITIALIZE command when the volume is initialized. On newly initialized disks, or less active disks, directories may tend to be near the outside of the disk. If they are expanded and relocated, the freed space will be reused for other files. Complicating things, pieces of now dead-directories may be found as remnants.

Reconstruction of disk structures requires care, it is easy to destroy information unintentionally. Use BACKUP/PHYSICAL to create a copy, put the original on the shelf, and work with the copy.

I am offsite at this instant, so I am working from memory without reference to documentation, but there are multiple copies of the both the home block and the boot block. For a start, since the space on the volume is allocated in multiples of blocks (clusters; not to be confused with either OpenVMS clusters or with the use of clustered allocation in Microsoft Windows(tm)), it is not surprising.

From your description, it is possible that the disk may have been initialized with a very large cluster size, and the padding you are seeing is filling up the first cluster.

As I noted before, if this data is valuable, I recommend extreme caution. One must proceed by gaining knowledge about the precise situation.

The first step is determining precisely how the disk structure was setup, and what precisely the problem is with mounting it. Many of the on disk structures have internal integrity checks, if these checks fail, OpenVMS will refuse to mount the volume. Similarly, repairs are not simply a question of patching a value, the various checksum values must be updated.

I have done a fair amount of volume adjustment and repair over the years. It can be done, but success requires a combination of care, patience, and careful reading.

- Bob Gezelter, http://www.rlgsc.com