vgcfgrestore restored the wrong info

[Anthony Hardwick]

We had a hard drive failure on an hp9000 and needed to have the drive repaired (there was no backup). After repair, we ran the vgcfgrestore command and an incorrect configuration resulted. there are several copies of the cfg file in /etc/lvm/conf, but they are all the same. Is there a way or a utility that would let us edit this binary config file manually and restore the correct lvol and partition size information?

[Patrick Wallek]

There is no way I know of to edit the vgcfgbackupe/vgcfgrestore files.

When you ran vgcfgrestore, what options did you use?

I generally do a 'vgcfgrestore -n /dev/vgname /dev/dsk/cXtYdZ'. It has never given me a problem.

You say that there was no backup of your data, so why not rebuild the VG from scratch before you restore?

[James R. Ferguson]

Hi:

I agree with Patrick. I presume that since you have no backup that there is no reason not to configure (from scratch).

In fact, you want your /etc/lvmtab to correctly reflect the proper state of your disks.

Therefore, I would 'lvremove', 'vgreduce' and finally 'vgremove' all structures in the damaged volume group.

Once this is done, verify that /etc/lvmtab is consistent with the remaining disks:

# strings /etc/lvmtab

If disks are mis-represented then do the following:

# mv /etc/lvmtab /etc/lvmtab.old

# vgscan -p # preview only

...and if the preview is correct:

# vgscan -v

# strings /etc/lvmtab

...JRF...

[Anthony Hardwick]

Thanks for the info. This disk (and a few others) are raw space with exclusively Informix BLOB data on them. I would rebuild from scratch but am worried about losing all the data if I do. The current 'definition' of this volume group has 10 partitions with only two 500 mb patitions active. What it should look like is 2 partitions of 1000 mb each. Does the method outlined by James leave my data intact and only 'rebuild' the configuration file?

[Jeff Gyurko]

There are a couple of things to keep in mind. When you did the vgcfgrestore, you either specified the VGConfPath which was wrong, or you changed something in the past and used the
-A option which does not take a backup automatically. If you did not specify the VGConfPath, then the latter should be the reason why the configs are wrong.

Either way, re-create is probably your only option, since your restoring anyway.

[Jeff Gyurko]

Anthony, I did not see your second concern before I posted, sorry. James' suggestions will not rebuild config file, but re-create the /etc/lvmtab file which is the "table of contents" for LVM. You might only be able to do this, after you've gotten the disk added back to the VG in question.

1. If the vgcfgrestore worked (even though wrong info). Do a "vgdisplay -v vgname" of the VG and ensure that "Cur PV" and "Act PV" are the same value.

If they are the same value, and the disk with the wrong cfg info in part of the VG, just do
a vgreduce and specify this disk. Once removed from the VG, you should have nothing else to do.

2. If "Cur PV" & Act PV" are different, and the vgcfgrestore does not work, try James' suggestion. I would deactivate the VG in question first with "vgchange -a n vgname"
before I did the vgscan. DONT rm the lvmtab
file either but save it as something else in
case there are problems. You do have to rename it for the vgscan to re-create it though, otherwise vgscan looks through this file for its information leaving you at square one.

These suggestions hinge on the fact that you say this disk you replaced had none of your data on it though. If true, you should be okay.

Let us know how it turns out.

[Anthony Hardwick]

Jeff,

Thanks for taking the time to write back again. If you could clarify one of your comments:
"These suggestions hinge on the fact that you say this disk you replaced had none of your data on it though. If true, you should be okay."
This drive actually does have data on it that we are need to preserve, as there is no backup. Amazingly, even with the wrong cfg file, users can access roughly half of the images stored in the raw file space. This is why my initial post was looking for a way to just change the cfg for this volume group.

[Jeff Gyurko]

Sorry for not coming back sooner.

My statement: ""These suggestions hinge on the fact that you say this disk you replaced had none of your data on it though. If true, you should be okay." was based on your comment that the VG was comprised on 10 LV's with 2 active. I was assuming that your disk was on one of the 8 non-active LV's with no information on it.

If you've had the bad disk repaired, NOT replaced (like it was the on-board controller that went bad) then your data should be intact. If the disk was replaced with a new disk, then you will have to re-create the VG.
The information on the bad disk is probably gone. If you have no backup, then you will most likely be facing a re-creation of the data. If you can backup or export the data on the remaining disks, then the re-creation may not be that bad depending on how much data you lost.

I'll read this more often until I hear back.