Volume becomes a shadowset member

[Rudolf Wingert]

Hello,
I did backup the system disk (OpenVMS 7.3-1) into a file and created with this saveset a system disk backup. During the latter operation the OS closed all my open windows, so I do know nothing about the status of the backup. I meant that it did finish successfull, opened a new window and did mount the system disk backup volume with the /OVERRIDE=IDENT qualifier. I did get the following system message: %MOUNT-W-VOLSHDWMEM. Does anybody have an idea, why this volume is a shadowset member. I did not initialize this volume as member and used the /NOINIT qualifier during backup.
Best regards R. Wingert

[Thomas Ritter]

Execute
$ sh dev sys$sysdevice

You system disk must be a shadowset.

You can mount the disk with /override=shadow

Look at help mount.

[Robert Gezelter]

Rudolf,

Perhaps I misunderstood your posting. If you did not see the final result from BACKUP during the restore, DO NOT USE the volume.

It is possible for the file structure checks during MOUNT to work, yet the data on the volume to be in an undefined state, depending on when BACKUP stopped. Unless you have positive indications of a successful restore, it is best to redo the restore.

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

[Jan van den Ende]

Rudolf,

did I read correctly that you mounted your restored backup as a data disk, or did you try to boot off it? If the latter, the SYSGEN data still holds the SHADOW_SYS_DISK setting, and uses that (but I guess that does not apply).
If the former, I have to make conclusions based on too little knowledge.
Based on your experience, I would guess that the membership history is NOT maintained in a data structure that is excluded by BACKUPs /NOINIT qualifier.

Volker, Hein, one of you have any pertinent onfo on the issue?

Proost.

Have one on me.

jpe

[Volker Halle]

Rudolf,

I've tested a quick BACKUP/IMA DSAx: LDAn: operation with /INIT and /NOINIT. In both cases, the destination disk was NOT a shadowset member and could be mounted with MOUNT/OVER=ID without an error message.

I have to assume, that your BACKUP restore somehow failed and left the destination disk in an inconsistent state. My tests have been run on OpenVMS Alpha F8.3.

Volker.

[Rudolf Wingert]

Hello,
there was some thing wrong with the first "restore". I did made a second one with success. I could mount this systemdisk copy as a normal disk. Thanks for all answers.
Best regards Rudolf Wingert