lost hard links after system restore?

[BoyeDav]

Okay, I'm an idiot. I did a full system backup prior to a drive replacement and neglected to use the /IMAGE option. I did boot to the OpenVMS DVD and did a BACKUP/IGNORE=INTERLOCk/VERIFY and backed up my system to a save set.

I have the system booted and everything *seems* fine, but shouldn't changes to SYS0.SYSCOMMON be reflected immediately in VMS$COMMON? Did I lose some aliases/hard links during the backup or restore, and what is the best way to fix them?

Our system volume was and is OD-5, and hard links were part of the default install for both the original installation. I checked this before the backup AND before the restore.

We're running OpenVMS 8.3 on Itanium (rx3600), single node. We're patched up to the June 2007 consolidated ECOs.

Thanks!

[Steven Schweda]

Without actually trying it, I'd guess that a
non-/IMAGE BACKUP would leave you with
separate, duplicate [SYS0.SYSCOMMON] and
[VMS$COMMON] directories. (And, perhaps,
some others, as well.)

> Did I lose some aliases/hard links during
> the backup or restore

Most likely.

> and what is the best way to fix them?

The only way I know is to reconcile the
contents of the should-be-the-same
directories, and then move the one which
should not exist out of the way, and use SET
FILE /ENTER to recreate the proper
alias/link for it.

On the bright side, you should recover some
wasted disk space when you delete the
redundant stuff.

[Jan van den Ende]

Boye,

>>>
Okay, I'm an idiot. I did a full system backup prior to a drive replacement and neglected to use the /IMAGE option.
<<<
I am really sorry, but I have to agree. Either that or you need some additional traing :-)

Seriously, you are not the first, and will not be the last.

Assuming you do not have the original drive (with content) anymore, Steven gave one recipy.
The other is a vanilla installation, & and applying all patches and layered products. (AND, this assumes you use the system disk ONLY as system disk, and not as storage for .)
Note that it may be wise mount this drive as data disk (boot off CD or use another system to mount the drive), since during the operation you DO pass though states that the system will not be able to address certain files. And _IF_ at such moment you try using one that is not already loaded, you will end up in limbo.

Bottom line: it can be done (had to do it myself, once by my own stupidity/incompetence, and several times to rescue others), But: take your time, make your plan first, do not hurry, do not let yourself be hurried.

Success!

Proost.

Have one on me.

jpe

[Robert Gezelter · Accepted solution]

BoyDav,

Ok, first please take a deep breath.

Is the original volume still available? Has the new volume been modified since the restore?

If the original still exists, and it is straightforward to re-do the BACKUP operation in /IMAGE mode, that is the easiest way.

If not, I would use BACKUP/LIST/FULL to produce a listing of the save set, and I would match files that have identical File IDs to verify what hard links existed.

I would then verify that the two sets of files have not diverged (in most cases, the hard links are for directories). If they are identical, I would correct the problem and delete the second set of files.

I do recommend extreme caution and care. I also recommend that a command file be used to verify that the files are indeed the same, as some of these directories have many, many files, and levels of directories.

I hope that the above is helpful.

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

[Robert Gezelter]

BoyeDav,

On reflection, a note of caution.

If a high level directory (e.g. VMS$COMMON) has an alias, all files below it in the hierarchy will appear to be aliased. To correct the problem, only the highest directory level needs to be fixed.

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

[BoyeDav]

renaming the duplicate directory and replacing it with a SET FILE/ENTER alias worked.

Aside from SYS0.SYSCOMMON/VMS$COMMON, are the other directories that VMS aliases in a plain vanilla install? I know we have not created any, so the only other ones that would need to be fixed would be ones created as part of the VMS installation.

[Jan van den Ende]

Boye,

>>>
Aside from SYS0.SYSCOMMON/VMS$COMMON, are the other directories that VMS aliases in a plain vanilla install?
<<<
Pure vanilla? No. But any clustering, or any STABACKUP. and: YES.
In any VMS system disk, ALL [SYSxxx]SYSCOMMON.DIR should be aliasses of VMS$COMMON.DIR

hth

Proost.

Have one on me.

jpe

[BoyeDav]

What about [sys0.sysmgr] and [vms$common.sysmgr]? Should one be the alias of the other?

[Jan van den Ende]

Boye,

>>>
What about [sys0.sysmgr] and [vms$common.sysmgr]? Should one be the alias of the other?
<<<

NO, no, no.

To find the distinction (and to get a better grip of the concept) do a
$ DIR/FULL of 000000.DIR, VMS$COMMON.DIR, and of SYS0DIR.
Note the FileID in the beginning of the output, and about 2 pages down the Directory Backlink Pointer.
Note that 000000 points back to itself (4,4,0), and the topDIRS also point back to it.
Now, look at [SYS0]SYSCOMMON. The FileID should be the same as that of VMS$COMMON, and the backlink is again (4,4,0). It _IS_ the same file as VMS$COMMON!
(try this for any normal file and the directory it is in, and the file will point back to the directory file).

And so you will find that [VMS$COMMON]SYSMGR.DIR is a _different_ file from [SYS0]SYSMGR.DIR.

In a standalone system this can be rather confusing in the beginning, but is is the heart of clustering (and of the easy upgrades compared to other OSes).

Look at the logical names SYS$COMMON and SYS$SPECIFIC, and at SYS$SYSROOT.

"the system" lives in SYS$SYSROOT, which is a searchlist. A searchlist is what the name implies: it is searched for the first match of any file specified.
So, in a cluster (or during upgrade) some files live in the SPECIFIC environment (during upgrades [SYSE], in a cluster a separate one for each node), but the bulk of the OS is the same for all nodes, and that needs to be present only once: in the SYSCOMMON tree.

The better you get acquainted with that concept, the more you will understand VMS, and the beauty of clustering.

hth

Proost.

Have one on me.

jpe

[Jon Pinkley]

BoyeDav,

You've probably learned more by manually fixing up everything that a non-image backup doesn't do that an image backup does.

However, as evidenced by your other questions related to this, you may still find other problems down the road.

Is there any way you can connect the original drive to a system and do the proper backup/IMAGE? If you still have this disk, I would recommend doing a backup/image from that device, if you want to be sure that you have a supportable system disk.

I am curious, how did you get the target disk to be bootable? At least on AXP and VAX systems, a non-image backup won't result in a bootable system disk, and extra steps must be taken to make such a disk bootable.

You may be interested in the following thread concerning disks with alias entries, and the easiest way to see what files have alias entries, the DFU program.

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

The reason your top-level directories didn't have the correct ownership/protection is due to a "feature" of BACKUP. You specified [*...] and therefore the directory files in the [000000] directory were not used as templates. The top-level directories on the output disk were recreated using the UIC and default protection of the process running backup. In your case that would probably be the SYSTEM account, I am not sure what the default protection is when booting from the DVD. If you would have specified [000000...] I believe the protection/ownership would have been correct.

One other issue that may or may not be important to you. All the creation dates on the directories will be the date at the time the disk was restored, not the original date from the source disk. If you use backup/image the directories are copied with the original dates intact. If SOX requirements affect you, you will probably need to document why these dates have changed.