vgexport/scan/import

[Matthew Couper]

Hello World!

I'm getting ready for another DR test soon and don't want to fall down at the same place I did last year :)

Last year I got stumped when the volume groups were not able to be restoreed correctly from the Ignite tape. The recovery machine is very simular to our live machine but the disk space is considerably smaller (only need to restore what is needed)

I've been reading the man pages for vgexport vgscan and vgimport (vgcreate and lvcreate I have under control, now) and think this would be a very useful method to restore vg01 (the only vg other then 00 that is needed). But typical HP man pages are difficult to read, it makes vgexport sound like it removes the existing vg's and saves it to a file...? And the "Sharable Option" sounds more like what I want to accomplish

Anyone have any good input on how to do this smoothly or a good page that explains it without contradicting itself?

Other then that, it's a breeze

HP-UX 11.00 HP9000 N4000 Enterprise Server

[S.K. Chan]

Have you take a look at HP's Software Recovery Handbook (chapter 16 LVM) ? If not here it is ..
http://us-support3.external.hp.com/iv/data/documents/DE_SW_UX_swrec_EN_01_E/Introduction.pdf
You may want to look at the section under "Replacing a Failed Disk". Vgexport and vgimport are typically used to rename a VG, moving a VG(its disks) from one path to another within the same system and moving a VG (its disk) from one systm to another. In a recovery situation vgcfgrestore is normally used to restore the LVM structure back onto the disk.

[Pete Randall]

Steve,

If the physical disks that contain vg01 are still available to you, you can vgimport them onto your Ignite restored server. The process is: vgexport -s -m /tmp/vg01map /dev/vg01 (obviously this gets done ahead of time); the /tmp/vg01map should get restored with your Ignite image; mkdir /dev/vg01; mknod /dev/vg01/group c64 0x010000; vgimport -s -m /tmp/vg01map /dev/vg01; vgchange -a y vg01.

If the physical disks are not avaiable to you, you need to re-create the LVM structures and restore the data onto the new disks.


Pete

[James R. Ferguson]

Hi:

A couple of comments. The '-s' option for 'vgexport'/'vgimport' isn't going to offer any help in recovery of your disks in a D/R environement. The so-called "shared" option adds the volume group's ID (VGID) to the mapfile created during the 'vgexport' process. When importing, physical disk can be queried and those with a matching VGID are imported and '/etc/lvmtab' updated. Obviously, you don't have your physical disks during a disaster, and hence the option isn't of value.

Too, the mapfile associated with a 'vgexport'/'vgimport' does nothing more than provide logical volume names for the (numeric) device numbers noted in the disk's LVM headers. A mapfile is simply this:

1 lvol1
2 lvol2
3 jrfsfs

Thus, if I want to name lvol3 "jrfsfs" then the above mapfile does that upon 'vgimport'. Whether or not I made the mapfile during the export process, or I made it afterwards with the 'vi' editor is immaterial.

The fact that your Ignite tape recovery "fails" is expected. You probably don't have any of the same hardware and device files at the D/R site that you have at home.

My preference is to create template scripts which start with a basic 'pvcreate' and follow through to the creation of filesystems for the servers I want to recover. Clearly, I don't know a priori the device files, or for that matter how many physical devices I will have at the D/R location, but I can fill that in then.

Regards!

...JRF...

[Matthew Couper]

Thanks Pete, that looks like exactly what I need. Using those options will only create the map file correct? It doesn't modify anything? The docs on it are a bit sketchy on that and I don't want to hose up a production server ;)

Chan, Thanks for that document! It looks like it will plug up a lot of holes I might have with this!

[Stuart Abramson_2 · Accepted solution]

You really want to re-read the note from JRF.

vgimport -s won't work at a D/R site!

It only works when you have the same physical disks.

You are going to have to recreate your VG device files from scripts at the D/R site:

mkdir
mknod
vgcreate
pvcreate
lvcreate
lvextend
newfs
mount -a

[Pete Randall]

Steve,

I'm glad you asked because I left out one very important option on the export. Use the -p flag (for preview). You're doing this beforehand to make sure you have the map you want, so you don't really want to export the VG. The -p flag will do just that: create the map file but not actually export the VG (which would make it inacessible to your production system until you re-imported it).

Pete

[Matthew Couper]

Thanks Stuart,
I noticed that, I took a while to make that last post so I missed his post and have been looking this over since.

What you just listed is very similar to what I have come up with. The vgexport/import are defiantly out.

Thanks for all the help!