Questions re shadowing

[Gerry Downey]

Hello,
I have a couple of questions regarding
shadowing. Should you be able to image a shadowed system disk to a bigger disk and then use the bigger disk as your system disk? I tried doing just that and I couldn't boot off the new disk.

Secondly, according to the shadowing manual, to dissolve a shadow set, you just dismount the shadowed volume. I did this on a shadow set and when I then mounted one of the physical disks that was in the shadow set it mounted writelocked as it was still a shadow set member. So my question is how do you dissolve a shadow set and then mount one of the volumes non-shadowed so that the data is fully accessible.

Thanks,
Gerry

[Volker Halle]

Gerry,

OpenVMS shadowing supports dissimilar device shadowing (DDS) and dynamic volume expansion (DVE) since OpenVMS Alpha V7.3-2. Make sure you're running with the most recent patches installed.

Did the shadow-copy complete, before you tried to boot from the bigger disk ? What were the error messages when you tried to boot ?

If you dismount a shadowset member from a shadowset and mount it privately, OpenVMS will protect the shadowing data on that volume by default, i.e. will mount the disk write-locked. You can mount the disk with /OVER=SHAD to enable writing to that disk. You then cannot put the disk back into the shadowset without a full shadow copy.

Volker.

[Gerry Downey]

Hello Volker,
Thanks for the reply. What I did was to boot the Alpha from an alternate disk, I mounted the system disk shadow set member (which mounted write locked) and then I imaged it to another disk. I didnt take note of the error unfortunately, and as I was then pushed for time, I just turned off system disk shadowing, then imaged the disk which worked ok. I was now able to boot off the new disk and I then turned on system disk shadowing.

Gerry

[Jan van den Ende]

Gerry,

>>>
I was now able to boot off the new disk and I then turned on system disk shadowing.
<<<

You did leave out some of that sequence, right?

To boot a shadowset (even if single-member) as system disk, you should TELL the system, by way of the system parameters, THAT it is to be a shadowed system disk, and, what the shadow set (DSA-) number will have to be.

And then the on-disk info (and, if applicable, the disks already present in the cluster) cluster do NOT prevent form a conlfict, only THEN will the node boot and use or form a shadow set.

In your first case, the (image of) your disk still contained conflicting info. So, the disk was NOT used, because that would cause damage to the data. First doing a MOUNT/OVER=SHADOW is the way to clear that particular conflict, but it has to be told explicitly beforehand.

hth

Proost.

Have one on me.

jpe

[Gerry Downey]

Yes I did leave out the sequence of setting up the new system disk to be a shadowed disk.

I'm just a bit concerned that imaging a shadowed system disk to another disk didn't work.

We have shadowed system disks that have been imaged to tape, we have never had to recover a system disk from tape but I'm wondering now if I imaged the system disk from tape, would that fail to boot as well?

[Jan van den Ende]

Gerry,

>>>
We have shadowed system disks that have been imaged to tape, we have never had to recover a system disk from tape but I'm wondering now if I imaged the system disk from tape, would that fail to boot as well?
<<<

Well, that depends.

If you want your restored system disk to be a restore from which you do a fresh cluster boot, then that just works.

But, if you want to restore that disk where you intend it to be co-existing with the original, you will need to change at least the label, and the shadowing params, and that you can NOT do if the disk still thinks it is a shadow member. /OVER=ID will cure that.

In between is the situation, where you want the restored disk for other purposes (e.g. to prepare to clone the system; or to prepare for a rolling update/upgrade). Now the shadowing system will detect that this is an older generation, and will write-lock the disk.

Again, same cure.

All this in true VMS style, to prevent accidental data loss or - corruption.

hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

Gerry,

In general, you can expand a correctly setup shadow set with little effort, as I described in my 2007 HP Technical Forum presentation, "Migrating OpenVMS Storage Environments without Interruption or Disruption" [slides available via http://www.rlgsc.com/hptechnologyforum/2007/1512.html ].

Doing this with a system disk requires some gymnastics, as the command to expand the volume (SET VOLUME/LIMIT) requires that the volume be mounted privately (at least on the 7.3-2 system that I have access to at this instant).

There are a variety of ways to "skin the proverbial feline", but they depend on your environment.

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