How to save an accidentally pvcreated disk?

[José Enrique González]

Hi:

Please consider this scenario and tell me if there is another solution other than backup and restore:

I have and ACTIVE volume group accessing data from two disks. Then I try to add the altern link of these disks (one at a time), but using a script that previously "pvcreate -f" the link to be added. When I execute the script I see 4 disks for the VG instead of 2 disks with altern links (because of te corruption generated for the pvcreate).

As every vgextend command saved a wrong configuration file in /etc/lvmconf, I have NO VALID conf file to vgcfgrestore. The VG is still active and accesible, but if I inactivate it I think it will not bring active again.

Any way to quickly and safely repair LVMREC for the disks? Thanks a million in advance for your suggestions.

Jose Enrique Gonzalez

[A. Clay Stephenson]

Do you have a backup (surely you do on tape) of the /etc/lvmconf directory on tape? If so, restore it and then use it to run vfcfgrestore.

[Mel Burslan]

so you did a pvcreate -f on the disks belonging to an already active volume group and these disks are still responding to data read/write requests as members of active vg and its lvols. Is this correct ? If so, tell your users to cease any activity on these disks and backup the contents of these disks as quickly as you can. In my opinion, you are sailing in uncharted territory. Longer you operate better your chances with ending up corrupt disks. More than likely, you will have to recreate the vg and the lvols under it. Then restore the data.

[Tim Nelson]

Jose,

You should be able to vgcfgrestore to that disk without loosing data.

I would however attempt to get a current backup of the data ASAP just in case the attempts to correct the error cause future access to the disk to fail.

The LVM configuration commands (pvcreate, vgcreate and lvcreate) do not destroy data on the disk but set the configurations on the disks headers for volume group membership and lvol names.

The vgcfgrestore will put back the vg header info tothe disk. I would be curious if vgdisplay complains ?

[José Enrique González]

Yes, vgdisplay works fine and show the current state of the VG. Data is still accesible and database is online. In fact, kernel structures are up-to-date, in contrast with LVM conf file.

However, I was able to vgcfgrestore LVM headers from a not-so-good conf file. It now allows me to do a vgcfgbackup, but this message appears when trying to vgchange -a y:

vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c11t2d6":
A component of the path of the physical volume does not exist.
vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c11t2d7":
A component of the path of the physical volume does not exist.
Volume group "vgsecaarc1" has been successfully changed.

So, I suppouse LVM headers are still corrupt.

[Tim Nelson]

Have you looked through your /etc/lvmconf directory to see if there might be a previous vgxx.conf file ? Some utilities like IGNITE create a .old file during their process.

[Tim Nelson]

Are the t2d6 and t2d7 devices mentioned the correct devices that belong to this volume group ?

You can view the contents of the vgxx.conf files with vgcfgrestore -l -n /dev/vgxx

You should get a listing like the below.
vgcfgrestore -l -n /dev/vgcache
Volume Group Configuration information in "/etc/lvmconf/vgcache.conf"
VG Name /dev/vgcache
---- Physical volumes : 4 ----
/dev/rdsk/c5t0d0 (Non-bootable)
/dev/rdsk/c20t0d0 (Non-bootable)
/dev/rdsk/c20t1d0 (Non-bootable)
/dev/rdsk/c5t1d0 (Non-bootable)
Then for example if c20t0d0 is the disk that had its LVM header wiped you can execute vgcfgrestore -n /dev/vgcache /dev/rdsk/c20t0d0

I am sure you are doing this but it does not hurt to ask.

[José Enrique González]

Well, it's obvious there's no easy solution to this ooops. I will plan backup and restore.