recovering LVM configuration

[Ian Lochray]

Our root disk died over the weekend. It has now been replaced and vg00 restored from an Ignite backup. My problem is the application data stored on vg01. Since the ignite backup was taken, two new disks (one is a mirror of the other) have been added to vg01 and two of the logical volumes have been extended onto the new disks. Since the recovery, these two disks are not available. Can I get them back into the configuration without losing data using vgscan?

[Ian Dennison_1]

You can copy off the existing /etc/lvmtab before running 'vgscan'. If it all turns to custard, you can re-instate this file.

You can also run vgscan in preview mode, to see what results it does get.

Note: If there are failover paths in the VG that were not there before (like SAN alternate paths) it will try and include these, and give warnings about them.

Share and Enjoy! Ian

[Bruno Vidal]

Hi,
I think that in you situation, the best things to do is:
1. keep a copy of /etc/lvmconf/vg01.mapfile
2. vgexport vg01
3. mkdir /dev/vg01
4. mknod /dev/vg01/group c 64 0x010000 (verify the minor before doing vgexport)
5. vgimport -m vg01.mapfile /dev/vg01 liste_of_your_device

Cheers.

[Michael Steele_2]

Well you've got two unrelated events going on here, A) The lose of your 'single' root disk restored from an ignite recovery, and B) The ignite recovery doesn't have any knowledge of the current state of vg01.

A) Need that alternate boot disk for situations like this as well as a cron job executing make_tape_recovery's at least once a month. Archieve these tapes offsite in a safe deposit box.

B) You've restored the server to a state that has no knowledge of the disks installed at a later time. So these current disk names can't exist anywhere on the server, like in /etc/lvmconf. They probably exist in the form of other backups other than ignite backups, so keep this in mind in case they are needed, but they're probably not.

B1) The data still exists on the data array and these disks know their LVM configuration from the configuration data stored in the LVM header. Using the '-s' option in vgexport and vgimport you can get these disks to join up in a newly created mapfile. Use this procedure:

ll -d /dev/vg01/group
Copy down the 0x0#0000 minor number.

vgexport -p -s -v -m /tmp/vg01_mapfile /dev/vg01 (* -p for preview *)

vi /tmp/vg01_mapfile (* review and rerun without -p option *)

Note: This will remove vg01 from the system except for the mapfile and LVM headers.

mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x0#0000
pvcreate -f /dev/rdsk/cXtYdZ
vgimport -p -s -v -m /tmp/vg01_mapfile /dev/vg01 (* -p for preview *)

Remove the -p option when ready.

B2) Check /etc/fstab. Since you've got and old copy of the O/S on your system it may not be up to date.

mount -a (* mount all file systems *)
bdf

[Bill Hassell]

In addition to the procedures listed above, you can always run SAM and look for volume groups that have not been imported. SAM will display these and you can select the unassigned disk(s) and give them a vg name (ie vg01). SAM will then import the disk(s) automatically and create the lvol device files. SAM will default the lvol names to lvol1, lvol2, etc, so if you used non-standard volume names, you can just rename the lvol (and rlvol) device files before you mount the volume.