Table of Contents
Introduction
Matching disks using UDIDs
Matching disks using Disk IDs
Reinitializing the disk while preserving existing data
Adding the disk back to the diskgroup with vxdg
Introduction
(Back to top)
If using vxconfigrestore is not possible, another method for recovering the disks is to compare the attributes of the disks with the records that are contained with the private region configuration database. In most cases, matching these disk attributes with records that are contained within the private region configuration database confirms whether or not the disk shown in vxdisk list (under the "DEVICES" column) is really the same disk that is reported in the "failed was" record.
Matching disks using UDIDs
(Back to top)
Using UDIDs is usually preferred over using Disk IDs because the Disk ID is contained within the Veritas private region and it may change if a disk is reinitialized, while the UDID remains the same.
Match the UDID that is recorded in the private region configuration database with the UDID that is found within the disk headers of any disks that need to be added back into the disk group. In most cases, a match confirms that the disk shown in vxdisk list (under the "DEVICES" column) is really the same disk that is reported in the "failed was" record.
1. Use vxdisk list to find the UDID from the disk header of a disk that needs to be added back into the disk group (Figure 1).
Figure 1 - Using vxdisk and grep to find the UDID for a disk in the disk header
|
Syntax:
vxdisk -o alldgs list
vxdisk list
Example, with typical output:
# vxdisk -o alldgs list
DEVICE TYPE DISK GROUP STATUS
disk_0 auto:cdsdisk - (vxfendg) online
disk_1 auto:cdsdisk - (vxfendg) online
disk_2 auto:cdsdisk - (vxfendg) online
disk_3 auto:cdsdisk datadg01 datadg online
disk_4 auto - - error
disk_5 auto:cdsdisk datadg03 datadg online
disk_6 auto:cdsdisk datadg04 datadg online
disk_7 auto:cdsdisk - (sambadg) online
disk_8 auto:cdsdisk - - online
disk_9 auto:cdsdisk - - online
sda auto:none - - online invalid
- - datadg02 datadg failed was:disk_4
# vxdisk list disk_4 | grep -i udid
udid: VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8
|
2. Determine if there is a record of this UDID in the backup copy of the private region configuration database (Figure 2).
By default, Volume Manager stores automatic backups of the private region configuration database to /etc/vx/cbr/bk//*.diskinfo. If a backup was taken manually, using with vxconfigbackup or privutil, the UDID may also be found there. If the UDID is found, note the value of the "Device" record to which it is associated. If this matches the UDID found in Step 1, then the disks are probably the same.
Note: Only use an enabled copy of the private region configuration database. Notice that in the output shown in Figure 2, the "config" has a status of "enabled."
Figure 2 - Searching for the UDID record in the backup of an enabled copy of the configuration database
Example, with typical output:
# less /etc/vx/cbr/bk/datadg.1336573086.38.Server101/1336573086.38.Server101.diskinfo
(excerpt from output)
Device: disk_4
devicetag: disk_4
type: auto
hostid: Server101
disk: name=datadg02 id=1356732184.45.Server101
group: name=datadg id=1336573086.38.Server101
info: format=cdsdisk,privoffset=256,pubslice=3,privslice=3
flags: online ready private autoconfig autoimport imported
pubpaths: block=/dev/vx/dmp/disk_4s3 char=/dev/vx/rdmp/disk_4s3
guid: {59b46d24-513a-11e2-a6ec-fa9f812341a3}
udid: MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8
site: -
version: 3.1
iosize: min=512 (bytes) max=1024 (blocks)
public: slice=3 offset=65792 len=2027264 disk_offset=0
private: slice=3 offset=256 len=65536 disk_offset=0
update: time=1356732621 seqno=0.13
ssb: actual_seqno=0.0
headers: 0 240
configs: count=1 len=51360
logs: count=1 len=4096
Defined regions:
config priv 000048-000239[000192]: copy=01 offset=000000 enabled
config priv 000256-051423[051168]: copy=01 offset=000192 enabled
log priv 051424-055519[004096]: copy=01 offset=000000 enabled
lockrgn priv 055520-055663[000144]: part=00 offset=000000
Multipathing information:
numpaths: 2
sdi state=enabled
sdl state=enabled
UUID=MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A99F54D1D5D2A12F
|
If no copies of the private region configuration database are available,
disk.info may be used as an alternative (Figure 3).
Disk.info only exists if disk persistence is enabled in
dmppolicy.info. By default, both of these files are found under
/etc/vx.
Figure 3 - Searching for the UDID record within disk.info
# cat /etc/vx/disk.info
VMware%5FVirtual%20disk%5FOTHER%5FDISKS%5FServer101%5F%2Fdev%2Fsda sda 0xc910 0x1 sda OTHER_DISKS OTHER_DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E38117220C5146E231 sdh 0xc990 0x2 disk_0 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3B0C237E3EE2B7225 sdg 0xc9b0 0x2 disk_6 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E381C85115F19A43F5 sdb 0xc970 0x2 disk_1 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3BBEC25236524B486 sde 0xc930 0x2 disk_8 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8 sdf 0xc9a0 0x2 disk_4 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3B53E871031307665 sdk 0xc960 0x2 disk_7 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3BF4B07325D4BE56F sdi 0xc940 0x2 disk_9 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E39848AE44D4AA3DB0 sdc 0xc950 0x2 disk_3 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E38CDDDB09DEB90282 sdj 0xc920 0x2 disk_2 Disk DISKS
VRTS%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A99F54D1D5D2A12F sdd 0xc980 0x2 disk_5 Disk DISKS
|
Matching disks using disk IDs
(Back to top)
It is also possible to match disks using Disk IDs. However, because the Disk ID is contained within the Veritas private region, it may change if a disk has been reinitialized, while the UDID will remain the same. For this reason, do not attempt to use Disk IDs to match disks if a disk has already been reinitialized, such as with vxdisksetup or vxdisk init. When a disk is reinitialized, the existing private region is replaced. This results in a new Disk ID that is different from the original.
1. Use vxdisk list to find the Disk ID from the disk header of a disk that needs to be added back into the disk group (Figure 4).
Figure 4 - Using vxdisk to find the Disk ID in the header of a disk
Syntax:
vxdisk -o alldgs list
vxdisk list
Example, with typical output:
# vxdisk -o alldgs list
DEVICE TYPE DISK GROUP STATUS
disk_0 auto:cdsdisk - (vxfendg) online
disk_1 auto:cdsdisk - (vxfendg) online
disk_2 auto:cdsdisk - (vxfendg) online
disk_3 auto:cdsdisk datadg01 datadg online
disk_4 auto - - error
disk_5 auto:cdsdisk datadg03 datadg online
disk_6 auto:cdsdisk datadg04 datadg online
disk_7 auto:cdsdisk - (sambadg) online
disk_8 auto:cdsdisk - - online
disk_9 auto:cdsdisk - - online
sda auto:none - - online invalid
- - datadg02 datadg failed was:disk_4
# vxdisk list disk_4 | grep -i disk:
disk: name=datadg02 id= 1356732184.45.Server101
|
2. Determine if there is a record of this Disk ID in the backup copy of the private region configuration database (Figure 5).
By default, Veritas stores automatic backups of the private region configuration database to /etc/vx/cbr/bk//*.diskinfo. If a backup was taken manually, using with vxconfigbackup or privutil, the UDID may also be found there.
If the Disk ID is found, note the value of the "Device" record to which it is associated. If this matches the UDID found in Step 1, then the disks are probably the same.
Note: Only use an enabled copy of the private region configuration database. Notice that in the output from the example below, the "config" has a status of "enabled."
Figure 5 - Finding the Disk ID within the backup of an enabled copy of the configuration database
Example, with typical output:
# less /etc/vx/cbr/bk/datadg.1336573086.38.Server101/1336573086.38.Server101.diskinfo
(excerpt from output)
Device: disk_4
devicetag: disk_4
type: auto
hostid: Server101
disk: name=datadg02 id= 1356732184.45.Server101
group: name=datadg id=1336573086.38.Server101
info: format=cdsdisk,privoffset=256,pubslice=3,privslice=3
flags: online ready private autoconfig autoimport imported
pubpaths: block=/dev/vx/dmp/disk_4s3 char=/dev/vx/rdmp/disk_4s3
guid: {59b46d24-513a-11e2-a6ec-fa9f812341a3}
udid: MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A7B206863B3B89A8
site: -
version: 3.1
iosize: min=512 (bytes) max=1024 (blocks)
public: slice=3 offset=65792 len=2027264 disk_offset=0
private: slice=3 offset=256 len=65536 disk_offset=0
update: time=1356732621 seqno=0.13
ssb: actual_seqno=0.0
headers: 0 240
configs: count=1 len=51360
logs: count=1 len=4096
Defined regions:
config priv 000048-000239[000192]: copy=01 offset=000000 enabled
config priv 000256-051423[051168]: copy=01 offset=000192 enabled
log priv 051424-055519[004096]: copy=01 offset=000000 enabled
lockrgn priv 055520-055663[000144]: part=00 offset=000000
Multipathing information:
numpaths: 2
sdi state=enabled
sdl state=enabled
UUID=MSFT%5FVirtual%20HD%5FDISKS%5F60003FF447A746E3A99F54D1D5D2A12F
|
Reinitializing the disk while preserving existing data
(Back to top)
Determine the offset and length of the public region. Then, reinitialize the disk using vxdisksetup. Specifying the public region offset and length allows Veritas to preserve the existing data while allowing flexibility for changes to the private region.
More details about reinitializing a disk, while preserving the existing data, can be found in this article:
"Reinitializing a disk while preserving existing data"
https://www.veritas.com/docs/000087673
Adding the disk back to the diskgroup with vxdg
(Back to top)
After the disk has been reinitialized, and the status is "online," use vxdg to add it back to the disk group
Figure 6 - Using vxdg to add the disk back to the disk group
|
Syntax:
vxdg -g -k adddisk =
Example, with typical output:
# vxdg -g datadg -k adddisk datadg02=disk_4
Vxdisk now shows that datadg02 is back in the disk group. Additionally, the "failed was" message is gone.
# vxdisk -o alldgs list
DEVICE TYPE DISK GROUP STATUS
disk_0 auto:cdsdisk - (vxfendg) online
disk_1 auto:cdsdisk - (vxfendg) online
disk_2 auto:cdsdisk - (vxfendg) online
disk_3 auto:cdsdisk datadg01 datadg online
disk_4 auto:cdsdisk datadg02 datadg online
disk_5 auto:cdsdisk datadg03 datadg online
disk_6 auto:cdsdisk datadg04 datadg online
disk_7 auto:cdsdisk - (sambadg) online
disk_8 auto:cdsdisk - - online
disk_9 auto:cdsdisk - - online
sda auto:none - - online invalid
|