Exporting and Importing VGs

[Andrew Brain or Yong Ji]

Hello,

I'm going to rebuild a K220 this weekend. I have 38GB of image data backed, but I'm hoping I won't have to restore it. I'm going to export it's volume group and bring it back after the rebuild.

I have no other unix people here with me, and I need someone to read through my plan and confirm it's ok, or say what I've missed out. Thanks

[Andrew Brain or Yong Ji]

PLEASE SEE ATTACHMENT
(CLICK PAPER CLIP PICTURE)

[Antoanetta Naghiu]

At first look, at midnight, looks ok to me!
Do not forget by the end to edit /etc/fstab to add the mount of fs or issue the mount command to do that.
Instead tar-ing the /dev/vg02, you can go and create the node group (see mknod command). Be sure when importing to have the physical disks in the same order.
I do not have man commend available right now, but, as far as I remember, in vgimport command, /dev/vg02 it is enough if is used at the begining.
If you still want to copy /dev/vg02 from old system, be sure the minor number of it is not already used.
As well you do not need to ftp the /etc/lvm/vg02.conf. vgimport command is doing it for you. If not, just use vgscan after import and you'll get it.
Good luck!

[Andreas Voss]

Hi,

so far to good but i wouldn't tar the whole /dev/vg02, only /dev/vg02/group file is needed:
tar cvf vg02.tar vg02/group
All lvol device files would be created at vgimport time.
After vgimport/vgchange -a y do vgcfgbackup /dev/vg02 to save the lvm info.

Regards

Andrew

[Emmanuel Eyer]

Things can be done simpler. Forget all about taring the files, it's not needed by export/import...

1. Umount filesystems, deactivate VG.

2. Run vgexport -m /tmp/vg02.map vg02
The vg02.map file contains the names of the lvols.

3. Transfer thru ftp or whatever the vg02.map file to the new system.

4. On the new system, assume there is no vg02 yet, neither a VG with ID 02 (can be checked by ll /dev/*/group, check two first digits of minor number, after 0x). If there is already a VG with ID 02, use something else (say 03). If there is a name conflict, use another one, but be careful about your filesystem device files...

5. Create the VG directroy (mkdir /dev/vg02) and the group file (mknod /dev/vg02/group c 64 0x020000 - be careful about the minor number).

6. Check the device files of the disks on the new system and import the VG running vgimport -m /tmp/vg02.map vg02 /dev/dsk/c0t4d0 ... (be sure to get all four disks, otherwise you will have to vgexport and vgimport again the whole VG)

7. Activate the VG (vgchange -a y vg02) and backup the config (vgcfgbackup vg02).

That's it! Hope it helps, Emmanuel

[Jim Mulshine]

I have done vgexport/vgimport just like in Emmanuel Eyer's suggestion. Just be careful, as he points out, to get your minor number right and use the new disk device file names that you get after the system rebuild.

[Larry Meade_1]

An even slicker way to do the vgexport/vgimport is to use the -s option along with the -m for vgexport/vgimport. This will put the vgid of the disks into the map file. This means that when you go to vgimport, you just point at the map file and don't worry about specifying all of the disks in the vg. check out the man page on vgexport/vgimport for more specifics.

[Alan Riggs]

Be careful when relying on the -s option. It relies upon the hardware paths/device files being identical. It works fine in those circumstances but can be dangerous when the paths do not align.

It is generally designed for use in HA clusters.

[Ramesh Donti]

Hi,
I agree with Alan that -s option should be used only in HA environment (shareable).
I recommend not to use this option especially when you are ugrading the system and chances are that ur device files might get changed.

Do vgexport in preview mode itself.
# vgexport -p -v

[R D SUNDAR RAJAN]

Beware of the import in ligical volumes that has a striping involved in ti which requires the exact order if the PV's .