LVM Restoration

[Brian Pyle]

After restoring my system (HP D370 running HP-UX 11.11) off a previously created make_recovery tape, the LVols in /dev/vg01 aren't recognized anymore. I did a vgcfgrestore for all the PV's, but I can't get any information on the LVol's or fsck them? What's the best way to set up my make_recovery so it will restore all of my logical volumes, not just vg00?

Thanx

Brian

[Sridhar Bhaskarla]

Hi Brian,

Can you successfully do a vgdisplay -v vg01?. After vgcfgrestore, you would need to do a "vgchange -a y vg01".

The safeway to recover the image is to disconnect cables to the storage, recover only vg00 and then import the other volume groups. So if you can keep the map files on a network servers, then they will come handy. This may be slightly time consuming, but can assure that the data is safe.

-Sri

[A. Clay Stephenson]

You should not have done a vgcfgrestore. You should have done a vgimport of your non-vg00 disks. Then a vgchange -a y and finally mounted the filesystems.

[Sridhar Bhaskarla]

He already did a vgcfgrestore. If he had a good backup before and had done it correctly he should be ok. The best he can do now is to do a vgchange -a y and see if his vgcfgrestore was successful.

Brian, the problem now is if you did vgcfgrestore on wrong disks, it could have updated incorrect LVM structures on those disks. However, vgcfgrestore does not overwrite the data extents. So, during the make_tape_recovery process, if these disks were not messed up, you may be able to recover your data provided you have good vgcfgbackup files and you used vgcfgrestore correctly on the correct set of disks.

You wouldn't have gotten into this situation, if you restored only vg00 by disconnecting the other disks. Rest is simple importing.

-Sri

[Ravi_8]

Hi,

You have to do vgchange -a y after vgcfgrestore. if this couldn't recognize vg01, then propably you might have used -x inc_entire=vg00 during make_recovery

[Brian Pyle]

Thanx everyone for all your help. For starters, I do have a good backup. Secondly this isn't a production machine. I have just never been able to restore my LV's that weren't in the vg00 very easily after a make_recovery install, and I am working with a sandbox machine to try to improve my record on this :) Previously I just rebuilt the Logical Volumes manually and recoverd the data to them. Arrgh :) Yes this is time consuming :) Initially I did a vgcfgrestore and then a vgchange -a y, as I thought that was the correct approach, and it did not recognize my LV's in vg01. Or at least it didn't make the connection between the LV's and the PV's. So I started over yesterday, and ran the recovery from the make_recovery tape again. This time I took Clay's recommendation and used the vgimport. This gave me an error that my VG was already in the /etc/lvmtab. So I did a vgexport, recreated the VG by hand with mknod. Then it appeard to go OK, but somewhere in the mix I must have stomped on the LV information on the PV's as Sri has suggested. I am certain that I am not doing these procedures correctly, and I guess what I'm looking for now, is the proper procedure to restore vg01 with minimal downtime, after recovering with a make_recovery tape. Then I'm going to scrap it and start over :)

Thanx For All Your Help

Brian Pyle

[monasingh_1]

I think vg01 not getting restored is not due to -x inc_entire option.
As far as I remember make_recovery does not have inc_entire option and make_net_recovery which does have this option is only to include all filesystems for that particular vg and it should not cause VGs other than VG00 or the included VG get disturbed.

There must have been something else wrong and vgimport should be the right way to go.And extream care should be taken while restoring to use only the disks which were used earlier for vg00 or included VGs.