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.