DP backup not backing up VMS$COMMON directory

[Manikandan.R]

We have an open VMS system with version 7.3-2 which is being backed up by DP version 5.5.
At the DP end the VMS$common directory is shown as file and not as folder so the restore from the DP backup misses the VMS$COMMON directory on the restored disk. Please let me know where the problem is at DP end or VMS end. And also how to recitify the same.

[Karl Rohwedder]

I have no knowledge of DP (dataprotector?), but I generally don't trust foreign products to correctly backup a VMS systemdisk.
We therefore regularly create image-backups of our systemdisks on datadisks using backup.exe.
Together with a OS-CD you are online again very quickly.

regards Kalle

[Uwe Zessin]

Well, Data Protector is a HP product, not really foreign and it was ported to OpenVMS by a person that has deep ties into OpenVMS.

Last time I checked, DP did not completely support OpenVMS system disks, though :-(
But you better check the documentation if you can live with these limitations.

I suggest you check if the data is available somewhere as [SYS*]SYSCOMMON.DIR;1

Many OpenVMS systems have a screwed-up system disk with an invalid filename (SYSCOMMON.DIR;1) in the header of VMS$COMMON.DIR;1 or a misplaced primary entry or something else. This problem (if it's yours, too) goes back to VAX/VMS Version 4 and has nothing to do with Data Protector.

[Guenther Froehlin]

The DP VMS client understands hardlinks like [SYSn.SYSCOMMON] on a system disk.

During a save it keeps track of the links and stores it in the save set. It does not go down a path that is a hardlink. On a restore it maintains a list in memory of the hardlinks found in the save set. At the very end it goes through and creates all the hard links.

This in fact creates a correct copy of a VMS system disk. During a save only files in [VMS$COMMON...] are saved and not in [SYSn.SYSCOMMON...].

I have tested this. It works (well, worked then). Make sure you have checked the hardlinks button and that VMS$COMMON.DIR has a backlink ID of (4,4,0).

/Guenther

[Uwe Zessin]

OK, but I was talking about the old-style directory aliases, not hardlinks.

We had chatted about the DP disk agent and its limitations at a DECUS symposium in Germany a while back, but maybe I don't remember correctly.

[Manikandan.R]

I checked the "BACK LINK FILE IDENTIFICATION" it is (4,4,0). But the "FILE NAME" is "syscommon.dir" instead of VMS$COMMON.DIR". I have attached the output please suggest.

Dump of file DSA0:[000000]VMS$COMMON.DIR;1 on 17-AUG-2007 15:43:28.26
File ID (15,1,0) End of file block 6 / Allocated 19

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: (15,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: 19
End of file block: 7
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,
MoveFile disabled
Caching attribute: Writethrough
Map area words in use: 3
Access mode: 0
File owner UIC: [1,1]
File protection: S:RWE, O:RWE, G:RE, W:RE
Back link file identification: (4,4,0)
Journal control flags:
Active recovery units: None
File entry linkcount: 0
Highest block written: 19
Client attributes: None

Identification area
File name: SYSCOMMON.DIR;1
Revision number: 18
Creation date: 15-APR-1997 19:20:21.91
Revision date: 19-FEB-2005 14:37:43.19
Expiration date:
Backup date: 23-JUN-2007 08:12:23.99

Map area
Retrieval pointers
Count: 19 LBN: 13176576

Checksum: 13619

[Edwin Gersbach_2]

Well, we have the same problem and I thought that's the way it is - until I've read this thread. I did a detailed analysis today and the first thing I noticed was, that this problem occures only on 8 out of 52 servers backed up by DP!

Unfortunately the ones I use most are among those 8. Kind regards to good old Murphy.

Further analysis revealed that the backlink is o.k. for all VMS$COMMON directories, but the file name in the identification section of the file header is different:

For those systems where VMS$COMMON is saved properly, the name is VMS$COMMON.DIR which is the name used in the [000000] directory.

For those systems where VMS$COMMON is saved as a file, the name is SYSCOMMON.DIR which is the name used in the [SYSn] directories. However, even in the SYSn path SYSCOMMON is saved as a file.

I have no clue where the bad name in the identification area comes from. I have found this bad name on 5 additional system disks out of 75 not backed up by DP.

Is there any way to fix this name?

Edwin

[Volker Halle]

See a recent discussion of the VMS$COMMON - SYSCOMMON problem:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1147991

Volker.

[Jan van den Ende]

Manikandan,

Somewhere back in history, your system disk has been restored in a timeframe where BACKUP did not handle directory aliases correctly.
Therefor now your first [SYSx]SYSCOMMON.DIR is no longer an alias, and VMS$COMMON.DIR is.

This is not uncommon, and can be rather easily repaired.

The issue came up recently:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1147991

Read through it, and find the instructions.

hth

Proost.

Have one on me.

jpe

[Guenther Froehlin]

Uwe, you're right. I meant alias entries and not hardlinks. Too long ago...too many other playgrounds.

And FTC (For The Records) DP can successfully save and restore a VMS system disk. Two things, though: You have to pre-initialize the disk before a restore and you have to run WRITEBOOT to make it bootable again.

/Guenther