Backup /image does not backup VMS$COMMON

[F. Boucher]

We are running VMS 5.5-2 on a cluster of 4 vax 6000-640.
I would like to transfer from the HSC controller the contents of the bootdisk to another disk.
I tried the following sequence:
backup /image /ignore=inter $1$DUA100: mua5:XPL0.BKP/save
To transfer to a tape the image of the system disk, then,
backup /image MUA5:XPL0.BKP/SAVE DKB400:
to restore it, but I get then the error messages:
%BACKUP-E-OPENDIR, error opening directory DKB400:[VMS$COMMON]
-SYSTEM-W-NOSUCHFILE, no such file

and the same messages for all the [SYS#.SYSCOMMON] directories.

Of course, the resultant DKB400: disk is unbootable, as there are no files in VMS$COMMON nor in any SYSCOMMON directories.

I also tried an analyse /disk, for $1$dua100: but got no significant errors.

How can I get a good backup of my system disk?

Thanks in advance,

Francois

[John Gillings]

Francois,

Probably not a good idea to reboot, as you may be surviving on directory cache!

It sounds to me like you have some serious structural problems on the disk. Does ANALYZE/DISK report any lost files? Can you see files in any of the SYSCOMMON directories?

Try this:

$ DIRECTORY/FILE $1$DUA100:[000000]*COMMON.DIR,[SYS*]*COMMON.DIR

You should see VMS$COMMON.DIR at the top, with the same file IDs as SYSCOMMON.DIR in each of the roots.

Assuming you have a VMS$COMMON.DIR, also check the backlinks:

$ DUMP/HEAD/BLOCK=COUNT:0 $1$DUA100:[000000]VMS$COMMON.DIR

the "Back link file identification" should be (4,4,0) and "File name:" should be VMS$COMMON.DIR;1

If they're not, you've found a problem. What you do depends on what they are.
If there's a version of DFU that works on V5.5-2, you might be able use it to repair the disk.

[Steven Schweda · Accepted solution]

> We are running VMS 5.5-2 [...]

A little behind the times, are we?

This sounds vaguely familiar. There was a
BACKUP problem and a patch:

ftp://ftp.itrc.hp.com/openvms_patches/archived_patches/vax/5.X/v5.5/vaxback4_u2055.CVRLET_TXT

See "APPENDIX C".

The actual patch kit is in that same
directory.

[Bill Hall]

Francois,

Verify that the current system disk (the one you backed) up is OK. The SYSCOMMON directories in all system roots must be aliases (or hard links) for the VMS$COMMON directory. To check whether this is the case, enter the following commands:
$ DIRECTORY/FILE_ID/NOHEADING/NOTRAILING SYS$SYSDEVICE:[000000]VMS$COMMON.DIR
$ DIRECTORY/FILE_ID/NOHEADING/NOTRAILING SYS$SYSDEVICE:[SYS*]SYSCOMMON.DIR

The file id should be the same for each. I suspect that the SYSCOMMON directories are aliases of one of the [SYSn]SYSCOMMON.DIR instead of SYS$SYSDEVICE:[000000]VMS$COMMON.DIR as they should be.

The freeware tool DFU might be able to fix this for you. I never used DFU way back in the VMS 5.5-2 days.

Bill

[Dean McGorrill]

I remember vaguely the backlink problem. I
had a file, in [0,0], that would do a
rename vms$common.dir to syscommon.dir and
back. but I don't remember the problem
as making a disk not bootable (?) Dean

[Hoff]

Hello and welcome to ITRC.

The usual trigger for this is an invalid BACKUP command, though there have been occasional OpeNVMS bugs in this area over the years, and BACKUP itself has seen various ECO kits. BACKUP syntax can be and often is confusing, so command specification errors can easily creep in. (I certainly learned to use BACKUP by making mistakes with it over the years, and I'm not alone here.)

It is usually feasible to stitch back together a file-based BACKUP; recover from and rebuild a file-based BACKUP. I've done this on various occasions.

That written, don't even bother with this particular BACKUP, as the /IGNORE=INTERLOCK permits (silent) data corruptions in the output. It's a whole lot more difficult to find and then recover from these sorts of silent errors.

At its simplest, have the disk privately mounted, and perform BACKUP/IMAGE ddcu: mmcu:saveset.bck/SAVE/VERIFY or equivalent. Or a disk-to-disk BACKUP.

I'd also be looking to replace the whole cluster configuration, as these VAX 6000 boxes are huge and slow and expensive to support and simply to keep powered up and cooled off. As are disks on an HSC-class controller. One Integrity server would run rings around this configuration, and VAX emulation is very likely viable here, and either approach would be less expensive than the power and the support costs going into this cluster.

Stephen Hoffman
HoffmanLabs LLC

[F. Boucher]

To all, We are not in a crisis situation (yet!) as the vaxes are runnning correctly, and the system disk is up and running.
So the disk is available to do tests and file structure tests.

I will start with the reply to John Gillings.
This is what the first command gave as an output:
$ dir /file $1$dua100:[000000]*common.dir,[sys*]*common.dir

Directory $1$DUA100:[000000]

VMS$COMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS0]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS1]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS2]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS3]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS33]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS35]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS36]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYS5]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Directory $1$DUA100:[SYSE]

SYSCOMMON.DIR;1 (11,1,0)

Total of 1 file.

Grand total of 10 directories, 10 files.
$

The DUMP/Head command gives:
$ DUMP/HEAD/BLOCK=COUNT:0 $1$DUA100:[000000]VMS$COMMON.DIR

Dump of file $1$DUA100:[000000]VMS$COMMON.DIR;1 on 26-JUL-2007 09:30:23.26
File ID (11,1,0) End of file block 3 / Allocated 8
File Header

Header area
Identification area offset: 40
Map area offset: 100
Access control area offset: 255
Reserved area offset: 255
Extension segment number: 0
Structure level and version: 2, 1
File identification: (11,1,0)
Extension file identification: (0,0,0)
VAX-11 RMS attributes
Record type: Variable
File organization: Sequential
Record attributes: Non-spanned
Record size: 512
Highest block: 8
End of file block: 4
End of file byte: 0
Bucket size: 0
Fixed control area size: 0
Maximum record size: 512
Default extension size: 0
Global buffer count: 0
Directory version limit: 0
File characteristics: Contiguous, Directory
Map area words in use: 2
Access mode: 0
File owner UIC: [SYSTEM]
File protection: S:RWE, O:RWE, G:RE, W:RE
Back link file identification: (4,4,0)
Journal control flags:
Active recovery units: None
Highest block written: 8

Identification area
File name: SYSCOMMON.DIR;1
Revision number: 9
Creation date: 28-APR-1988 19:11:42.42
Revision date: 29-NOV-1994 18:11:01.41
Expiration date:
Backup date: 25-JUL-2007 23:17:36.34

Map area
Retrieval pointers
Count: 8 LBN: 2678056

Checksum: 11849
$


The back link identification is (4,4,0).

So, the problem might not be sooo bad, that makes me get a smile back on my face! :)

I think the DFU suggestion might be a good track for this.

John, I thank you warmly for your help so far, if you have more for me, I will try it!
Now, the reply to Steven Scweda's suggestion:
I think you might have the jackpot! but i am scared to correct the problem as described in appendix C:
$ SET DEFAULT DISK:[000000]
$ SET FILE/ENTER=SYSCOMMON.DIR VMS$COMMON.DIR
$ SET FILE/REMOVE VMS$COMMON.DIR;
$ RENAME SYSCOMMON.DIR VMS$COMMON.DIR
But the symptom described by the link you give me sure looks as the problem i have.
So I thank you very very much as this is a very valuable piece of information.
As for behind times, i would describe our actual setup as a living computer museum!
Can you imagine we still have some TU82 reel to reel tape drives here?

Bill Hall's suggestions gives the following outputs:
DIRECTORY/FILE_ID/NOHEADING/NOTRAILING SYS$SYSDEVICE:[000000]VMS$COMMON.DIR
SYS$SYSDEVICE:[000000]VMS$COMMON.DIR;1
(11,1,0)
$ DIRECTORY/FILE_ID/NOHEADING/NOTRAILING SYS$SYSDEVICE:[SYS*]SYSCOMMON.DIR
SYS$SYSDEVICE:[SYS0]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYS1]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYS2]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYS3]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYS33]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYS35]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYS36]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYS5]SYSCOMMON.DIR;1
(11,1,0)
SYS$SYSDEVICE:[SYSE]SYSCOMMON.DIR;1
(11,1,0)
$

It seems that all *COMMON directories point correctly to the same place, (11,1,0), which means that the disk as a correct structure, and the problem is maybe a little bit more around the old BACKUP executable we have here. Thank you very much, Bill, for your help, i really appreciate it a lot!
I don't know DFU, but as there are a few people who recommends it, I will take the time to learn it.

Dean, Thanks also for the pointer, but the tests so far indicates more a BACKUP utility problem than a disk structure problem (Please anybody, correct me if I am wrong!).


To Bill Hoffman: I did check your site and the various howto for the disk structures you did put on the web, i think this info is good to help me understand VMS management and internals. Also, your suggestion of migrating the machines to simulators is extremely good, as this is what I am doing, and this is why I need to migrate the system disk into a VAX simulator. The migration does not work, as the backup is not good. As i told my boss, there are two times where you learn your backups are bad: 1) while restoring them for a migration, or 2) while restoring them when you absolutely need them after a disk crash... Of course, he prefers option 1)...
I already tried your suggestion, but the backup problem is still there. I could try a disk to disk, but with the HSC controller only. I will give it a try! Thank you very much, Stephen!

[Jan van den Ende]

Francois,

Welcome from me to.

From your text:
>>>
$ DUMP/HEAD/BLOCK=COUNT:0 $1$DUA100:[000000]VMS$COMMON.DIR

Dump of file $1$DUA100:[000000]VMS$COMMON.DIR;1 on 26-JUL-2007 09:30:23.26
.
.
.
Identification area
File name: SYSCOMMON.DIR;1
<<<

So, you DO have the VMS$COMMON - SYSCOMMON alias swithcing!

Now, the reply to Steven Scweda's suggestion:
I think you might have the jackpot! but i am scared to correct the problem as described in appendix C:
$ SET DEFAULT DISK:[000000]
$ SET FILE/ENTER=SYSCOMMON.DIR VMS$COMMON.DIR
$ SET FILE/REMOVE VMS$COMMON.DIR;
$ RENAME SYSCOMMON.DIR VMS$COMMON.DIR
<<<

You are scrared, (and probably rightly so if things are somewhat unclear) but WITH this evidence, it is they exact correct repair procedure! Do take care when typing, be justly scared of typos, but, DO it, and you will be OK.
I have had to do it myself a few times (although my memory has it in the V6 timesframe).

Succes!

Proost.

Have one on me.

jpe

[Steven Schweda]

> [...] but i am scared to correct the
> problem as described [...]

Scary or not, I believe that that _is_ the
solution. A quick Google search for:

SYSCOMMON.DIR VMS$COMMON.DIR

found:

http://www.s-and-b.ru/syshlp/vmsu2055.release_notes

which says the same thing. As I recall, some
other official documents (VMS upgrade
instructions?) also asked the system manager
to do this check, and to correct the problem
this way. (I'm pretty sure that I needed to
do this once, but it's been a long time, and
my memory is less reliable than it was when
I think that I did it.)

What could go wrong?

[Volker Halle]

Francois,

if your main concern is getting the system disk over to the emulated VAX and you are willing to try the 'repair' operation there, you could do the following:

Make a BACKUP/PHYSICAL of your current system disk. To do this, you would need to mount that disk /FOREIGN, which can only be done by booting one of the machines with standalone backup and doing a BACKUP/PHYS $1$DUA100: tape:saveset.bck/save.

The resulting backup may not be consistent (same as with your BACKUP/IMA/IGN=INTER), but it should allow you to restore a bootable disk on the emulator and try the 'repair' operation on the SYSCOMMON.DIR file.

I just tried >>> B/E000000 on a CHARON-VAX emulator (running SA-Backup V5.5-2H4) and a BACKUP/PHY disk: tape: - it works.

Volker.

[F. Boucher]

Hi to ALL! well, i did follow the advice of Steven Schweda, and did the following:
1) downloaded and applied with VMSINSTAL the ECO kit for backup4 that is referenced before.
2) applied the solution that is listed in appendix C of the ECO readme. Jan van den Ende and Volker Halle also references the same 4 commands, and I applied them exactly as Jan van den Ende listed them.

3) Did a BACKUP /IMAGE of the system disk, restored it on the target system (simulator) and succeeded!. The simulator did boot correctly with the restored disk image.

I am now quite satisfied with that.
I would like you all to warmly thank you for your most valuable help, as I resolved my problem, and from now on, I have a GOOD system disk backup.
We were, without knowing it, on the verge of an indescriptible crisis, if the system disk would have crashed, and the backup would not be usable for a restore!
Again, Thank you all for your help! and as Steven says, I will have one on him! cheers!

[Dean McGorrill]

>So, you DO have the VMS$COMMON - SYSCOMMON alias swithcing!

that was the reason I always kept a little
com file up in [0,0] on the system disk to
fix the file id. and I'd set default there
to run it. Dean

[John Gillings]

Francois,

The VMS$COMMON SYSCOMMON alias problem was quite common back in V5 (certainly more so than it is today). I consider it a design flaw, the original mistake was to call the "real" file VMS$COMMON and all the alises SYSCOMMON. If they'd all been given the same name, this particular error simply couldn't happen.

The RENAME method is correct when the backlink is correct (4,4,0) and the file name is incorrect. It does NOT work for other permutations (and there are many!).

For V5 systems, I recommend you create another alias in [000000] called SYSCOMMON.DIR with

$ SET DEFAULT DISK:[000000]
$ SET FILE/ENTER=SYSCOMMON.DIR VMS$COMMON.DIR

Leave SYSCOMMON.DIR on the disk, just in case the alias name flips again (things like an image restore using some versions of V5 BACKUP will change the filename). The advantage is, no matter which name gets into the file header, resulting filespecs will be valid. They'll just use the "incorrect" SYSCOMMON directory path instead of VMS$COMMON.

On later versions of OpenVMS, BACKUP is better at keeping the backlinks correct, ANALYZE/DISK will report it and we have DFU to fix it without those scary renames.