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

[Jon Pinkley]

Guenther,

Do you know if it is possible to install DP on a bootable CD so it would be possible to do a "bare metal restore" of a system disk?

Jon

[Robert Gezelter]

Jon,

I suspect it is not so much a question of a "bare metal" CD/DVD as it is a question of a special purpose node.

Creating a CDROM/DVD of a special purpose node, and using the memory disk for paging (or no paging file at all) can certainly be done. For that matter, that has been feasible since at least the VAX-11/750 days.

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

[Jon Pinkley]

Ok, I will ask the question stating only the goal.

If DataProtector is being used as the only backup for both system and data disks, what is the recommended procedure to minimize the time required to get a working system up at a disaster recovery site?

Jon

[Guenther Froehlin]

Well, there were plans to incoporate enough DP context on the OpenVMS Installation DVD to be able to do a DP restore like for a complete system disk. I have not heard of that this was ever implemented.

The way the DP VMS client worked then it required a writable disk for some housekeeping files and TCP/IP up-and-running. If that is still true then it might be a bit more work to make such a bootable DVD with a nice DP startup so the DP client finds the current DP Cell Manager node.

Without a bootable media like this you have to restore your system disk first using BACKUP and also restore any other disk containing DP data (which is by default kept on the system disk). Then you can start a restore operation through the DP Cell Manager through some other node's DP GUI.

/Guenther

[Dean McGorrill]

hi manikandan,
I used to have a little com file in [0,0] of my system disk to rename vms$common.dir to syscommon.dir and
then back to vms$common.dir. This fill fix
your file id name. Dean