DS25:Shadowset member failure

[Learn_1]

Hi all,
We are having problem of disk failure of SW4354 connected with DS25 running OpenVMS. Volumes are shadowed and one of the shadow set member $1$DKB100: is causing problem by reporting error count. Shadow set members are of 18.2 GB 15K U320 connected with the system via Dual channel SCSI Adapters. I am also attaching the output of a command displaying the status of the shadow set members.
i want to remove the faulty disk from the system and want to add new disk.following is the procedure that i am going to perform.Please suggest any modification in the procedure or any precautionary measures that needs to be follow before applying this procedure.
1.Remove the faulty disk from the storage shelf. (Do we need to perform any procedure before removing this disk from SW4354)
2.Insert the new disk in place of faulty drive and let it spin up.
Issue the following command and verify that the newly added device is shown as $1$dkb100
PK31: SYSTEM> show device d

3.If disk is not shown as above, run IOAutoconfigure so that System scan for newly added device

PK31: SYSTEM> mc sysgen

SYSGEN>io autoconfigure

5.Initialize the newly added disk so that system may write file structure to disk
PK31: SYSTEM>init $1$dkb100: backup (what if we do not know the label of faulty disk)

6.Now add this new disk to shadow set as follow
PK31: SYSTEM> mount DSA1: /shadow=$1$dkb100: SMSC_SYS

7.After issuing this command the newly added disk will be added to shadowset member and copy process will start automatically.

Similarly issue the following command which will display the shadow set member.The members should $1$DKB100 and $1$DKC100
PK31: SYSTEM>show device/full DSA1

Please suggest any modification if required.
Thanks

[Martin P.J. Zinser]

Hello,

the procedure looks ok. Still I would add a
Step 0: full backup of dsa0 to tape. Since this
seems to be your system disk you might have done that anyhow...

Greetings, Martin

[Mike Naime]

Actually I think that it was DSA1 that was missing the member, not the system pack.

I would recommend that you do IO SCSI, and then IO AUTO. Since you already see DGA100, this device will not go away until your next re-boot. Since you are not re-booting the system, you will need to clean up, and then add back.

IO SCSI_PATH_VERIFY will go out and verify all of your devices, and cleanup anything that is not currently active. (set it offline) When I remove drives for use elsewhere. I run the IO SCSI so that it sets the devices to OFFLINE. This way nobody tries to mount those disks.

You may actuall want to run IO SCSI as step 1B before inserting the new drive.

[Learn_1]

Hi,
Thanks for your suggestions.
Just want to ask one thing.
as one member of the shadow set is online and serving the application do the label of the disk that i will initialize for adding it to shadow set should be the same to that which is already in the shadow set although the vollume lable of the shadow set will be the SMSC-SYS.
for example if the volume lable of the disk $1$DKC100 is test should the volume lable of the new initialized disk should also be test or it could be different.
Also how can we check the volume lable of the $1$dkc100; which is mounted in shadow set.

[Andreas Vollmer]

Hello,

The previous recommendation are correct but
I would suggest following actions in order to recover the failing disk.
I assume that you have an AlphaServer such as a DS or ES therefore we must use the SYSMAN utility...

0) Check for a valid backup...
1a) Check the current operator.log for
following information:
- When (date & time) the failing disk
dropped out of the shadowset
- What is the name of the shadowset...
1b) Check also the mount script (issued
during system startup) to which
shadowset the faulty disk belongs.
! Don't do any assumptions double check!
2) remove the faulty disk
3) insert new replacement disk
4) Issue following cmds:
$ MCR SYSMAN IO AUTO
! issue this cmd always after a
! device replacement
5) init the new disk with a dummy label and
do a test mount (avoiding a DOA)
$ MOUNT/OVER=ID $1$DKB100:
! if all looks OK then continue otherwise
! get another disk
6) Check the existent shadowset for label
etc.
$ SHOW DEVICE DSAn:
7) mount the disk SYSTEM wide back into the
correct shadowset (xxxxx = volume label):
$ MOUNT /SYSTEM -
DSAn: -
/SHADOW=($1$DKB100:) -
xxxxx xxxxx
8) Check all works fine by issuing:
$ SHOW DEVICE DSAn:
! issue this cmd several times in order
! to check the shadowcopy progress
9) Finish

[Andreas Vollmer]

Hello again,

Sorry I am tyred and forgot some parts.
... and yes, you have a DS25...


0) Check for a valid backup...

1a) Check the current operator.log for following information:
- When (date & time) the failing disk dropped out of the shadowset
- What is the name of the shadowset...

1b) Check also the mount script (issued
during system startup) to which
shadowset the faulty disk belongs.
! Don't do any assumptions double check!

2) remove the faulty disk

3) insert new replacement disk
4) Issue following cmds:
$ MCR SYSMAN IO AUTO
! issue this cmd always after a
! device replacement
5) init the new disk with a dummy label and
do a test mount (avoiding a DOA)
$ INIT $1$DKB100: test
$ MOUNT/OVER=ID $1$DKB100:
$ DISMOUNT $1$DKB100:
! if all looks OK then continue otherwise
! get another disk
6) Check the existent shadowset for label
etc.
$ SHOW DEVICE DSAn:
7) mount the disk SYSTEM wide back into the
correct shadowset (xxxxx = volume label):
$ MOUNT /SYSTEM -
DSAn: -
/SHADOW=($1$DKB100:) -
xxxxx xxxxx
8) Check all works fine by issuing:
$ SHOW DEVICE DSAn:
! issue this cmd several times in order
! to check the shadowcopy progress
9) Finish

[Learn_1]

Hi Andreas,
thanks for detailed description.
Just want one clarification.in your script you mentioned
"5) init the new disk with a dummy label"

should't this label be exactly as of shadow vloume label as in my case it is SMSC_SYS.so when i'll initialize the new disk it should be like.
init $1$dkb100: SMSC-SYS

please clarify if i am wrong.

[Juerg Eichenberger]

In this case you can initialize the disk to whatever label. It gets overwritten by the shadow copy operation anyway.

Try to use the /CONFIRM qualifier ...

mount /SYSTEM /CONFIRM DSA1: ......

Regards
Juerg