VMS Disk Init

[Alan Kerr]

I have init'ed the wrong disk, on a VMS system.
on an emulex 8" dua0,disk drive. is there any way
to undo init and restore the disk as before?

[Steven Schweda]

BACKUP is the best way, but it requires some
preparation. INITIALIZE does tend to
overwrite some useful data.

I haven't heard of a magic method to recover
from this, other than (expensive) data
recovery services.

[Robert Gezelter]

Alan,

Unless you are VERY lucky, NO. If the first INIT and the second INIT both used the default values, then it overwrote the same areas on the disk.

How critical is the data on the disk?

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

[Volker Halle]

Alan,

welcome to the OpenVMS ITRC forum. Sorry to hear, that you've come here because of this unfortunate event.

First of all, WRITE PROTECT the disk and make a BACKUP/PHYSICAL copy of it to secure the physical contents of that disk.

There is NO WAY to automatically re-do the effects of the INIT command. Depending on the parameters of the INIT command, it has overwritten the most critical parts of the on-disk file structure and possibly also some of your data files.

The most critical data are the file headers, which specifiy the physical location of the varous part of the data files on disk. File headers have a checksum and a distinct layout, so they can be found using a raw LBN scan of the disk.

The DISKBLOCK utility (OpenVMS Freeware, URL: http://h71000.www7.hp.com/freeware/freeware70/diskblock/ ) can find valid file headers on the disk:

$ MC DISKBLOCK
DISKBLOCK> SEL/NOWRITE DUA0:
DISKBLOCK> SEA/HEADER

Start with this command and see, how many file headers of your 'old' files are found.

Then consider to get help of an experienced OpenVMS consultant with in-depth knowledge of the ODS-2 file structure to help diagnose, if at least partial recovery of the data may be possible.

Volker.

[Robert Gezelter]

Alan,

I must second Volker's comments. IMMEDIATELY physically remove the disk from service. The safest place is in an anti-static bag, inside the safe, marked DO NOT TOUCH.

A physical mode backup, alternatively a forensic backup) is a good suggestion. And, having dealt with the internals of FILES-11 (1, 2, and 5), you can do things yourself, but a very thorough understanding of the file structure is essential to this type of recovery.

One time, many years ago, pre-BACKUP, I had occasion to reconfigure the cluster factor of a disk in-place. There were no spare drives, no spare packs, and only a tape drive for backup. If I had not studied the FILES-11 specification in detail, the task would have been impossible.

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

[Hein van den Heuvel]

Of course I largely agree with Volker and Bob, but I think the first and foremost questions are:

1) how valueable is the data on the disk?
2) how good is your backup?
3) can you reconstruct your data from other sources? For example, if it was a system disk, just re-install VMS and such (yeah I know, easier said than done).
4) what is the timeline needed to recover the data?

Personally I have not seen an 8" DUA0 style disk active in over 15 years. THerefor, I'm thinking that this may be an older, stable, environment, where even old backup may be relatively valuable.

Personally I have never been able to justify the time to recover from an init, because it is likely to take a while, but I'm less pessimistic than the others.

If I were to have to deal with this (and I could for mere money, just send me a mail :-) then I'd start by (re-)learning the exact details of what init does. I'd create an LD disk and trace the IOs, mapping them back onthe the resulting disk structure. It will write the new indexf.sys... but does it overwrite anything beyond the minimum? and so on.

Then I'd problaby make an attempts by just flipping all the bitmap.sys bits and the indexf.sys internal bitmap to allocate and 'see' what comes back to live... just in case the init just the exact same layout as before.

But most likely you need to manually attach file header to the new indexf... in the old place (FILE-ID). And 000000.DIR is ofcourse cleared, but that's not a big deal.

The tool volker mentions probably does this, or can help with this, After all, file headers are very recogizable (word offsets, name, checksum) and there are travel in bunches (the old indexf extents), and you know where in indexf.sys they should live (the file id)

Good luck,
Hein.

[Thomas Ritter]

We had a similar problem whereby a production disk during a maintenance windows had all of its files deleted. Because we run a traditonal setup with development hosts followed by test hosts and then production, we were able to recover most of the data from the test hosts. We lost log files and some configuration files but no data files. We keep copies of all configuraton data in a number of locations. We were able to restore the services offered by the disk within 30 minutes. The recover time was quick largely because of the skills and readiness of the system adminstrators. We also could have recovered the data from tapes. That would have taken much longer. Learn from the experience. Losing data is one thing, but facing the prospective of paying compensation or penality payments or litigation is another. Or losing your job...

Thomas.