Reclaiming lost volume groups..

[SuperDome_1]

Hi Gurus..

I'm trying to reclaim a volume group on XP-128 Disk, that was lost due to a Brocade switch that had to be removed, for various reasons. I've connected up another switch to the server / XP-128 SAN, and can see the same # of disks, although the logical device names have all changed. (The current disk device names don't match any of the disks in my saved /etc/lvmtab). I also had to recreate the /dev/vggrp directory, and the group device name, since those were also removed (I used the same device #). Is it possible to retrieve the lost vol .grp using some combination of vgimport and vgscan, or not.. in which case I can restore the entire code tree from tape...

Thx

I've attached the output of the vgscan -pv and the previous saved /etc/lvmtab here, as well as a current copy of the output of ioscan -fnC disk and inq.. The vol. grp that I'm trying to recover is vgapp1

Thx in advance..

[Massimo Bianchi]

Hi,
if you have a vgexport prior to the removal of the brocade, it would help, but i think it's not your case.

So, let's go in entertainment (i have had a good new, and i'm quite happy..)



1- create a mapfile with the sintax

# lvol#


for the number of lvol in your ex volume group.

if in doubt, put a number of disks higher than expected, vgimport operation will complain.

reduce untill the expected number

2A- if you know the disks, issue the vgimport using the previous created mapfile, and it's done.


2B- you know at least one of the disk of the previous vg

extract the VGID with this command

echo 0x2010?2X | adb /dev/dsk/c0t6d0 | expand | tr -d " " | sed "s/2010:/VGID /" >/etc/vgid.map



substituing the disk with one of yours.
Then create the mapfile with the VGID in the firstline, like in my example:

VGID 5c32171b3afa38aa
1 lvol1
2 lvol2
3 lvol3


-2C you don't knon any of your disks...
use the inq utility to find at least one of the disk, and after go to point 2B.

If it is not clear, ask freely !

HTH,
Massimo

[Michael Steele_2]

Regarding "...I've connected up another switch to the server..."

Your bad luck because with new device names and new disk ids you can't do it.

Ordinarily you can recall the LVM header residing upon each disk by the VGID but they will only respond to their own disk ids.

For just this reason of resiliency you should have a backup brocade switch in place in case one fails.

Here is the procedure under these conditions:

vgexport -p -v -s -m /tmp/mapfile /dev/vg##

(* -p preview *)

Review mapfile

mkdir /dev/vg##
mknod /dev/vg##/group c 64 0x0#0000
vgimport -s -v -p -m /tmp/mapfile /dev/vg##

[George_Dodds]

If i remember right you have to have had vgexport'd the volume group before you can import it.

Maybe you can use vgcfgrestore.

[Ian Dennison_1]

Initial analysis,....

Looking at the file lvmtab.052103, you have 8 disks in /dev/vgapp1 (each visible down 2 controllers) - right?

Now, EMC Arrays control the "tYdZ" number that is presented for the device name, but the interface you see it through determines the "cX" number (eg cXtYdZ)

By a process of elimination, there is only 1 set of disks that shows cXt2d0 to cXt2d7 (the range shown in the old lvmtab) and that is c27t2d0 to c27t2d7.

Work through this yourself until you are happy with it (if you like, do an 'inq' and then print it, then work through the results of 'strings /etc/lvmtab' striking off each disk that you know is already allocated). You can even compare the current disk devices names on the new VGs to the old disk devices on the old VGs to confirm that the tYdZ numbers stay the same!

By a process of elimination, you should be able to identify the disks you need.

A vgimport will work if the VG Minor Number is the same, but may warn that the disks belong to a different CPU ID (this is nothing to be concerned about if you have done your homework correctly).

Share and Enjoy! Ian

[James R. Ferguson]

Hi:

'vgexport' the volume group in question. You could use the '-f outfile' argument to capture the old device file names. Then, edit this file to reflect the new device files and use it in a 'vgimport':

# vgexport -v -m mymapfile -f mypaths /dev/vgapp1

# vgimport -v -m mymapfile -f mypaths /dev/vgapp1

This method allows you to maintain the primary and alternate path arrangements you originally had since you are specifying the (new) device file order during the 'vgimport'.

Regards!

...JRF...

[SuperDome_1]

Thx for all your replies..

I was able to create the basic mapfile, using Massimo's recommendations, and I only had the one logical vol. in that that vol. grp. So now I have the following

VGID 135fb6a83ebf96ba
1 lvapp1

Then I'm going to use George Dodd' suggestion to use vgcfgrestore, since I have a copy of the xpinfo -il from before the switch was disconnected, and will compare with the current xpinfo -il output and use vgcfgrestore -n /dev/vgapp1 -o /dev/rdsk/cXtXdX /dev/rdsk/cXtXdX and so on..

I'm guessing that might actually work..

Thx

[Massimo Bianchi]

Hi,
if you have the VGID, use the

vgimport -s -m mapfile vgname


It will search the disks for you !

Massimo

[SuperDome_1]

Thx That did it..

Although I was surprised that it worked even though I took the vgexport after the switch had been disconnected.. (Since it has the same VGID, it worked.) I then checked and saw whether they were the same disks, by comparing the output of the xpinfo now, to one that I had saved before..

Thx again Massimo..