To recover LVM volume group, even if pvremove was executed on PVs

[Senthil Kumar .A_1]

The procedure's outlined here is purely the result for some tests I performed on a test HPUX box in my organization. I'm not too sure whether the following procedures are already in place in HP. But, this is my earnest effort in sharing the knowledge I have gained: to my HPUX peers so as to make the HPUX admins more prepared incase of some unusual situations that might be encountered in LVM parlance.

As a point adder â I love LVM, Though it might be considered ,complex in implementation compared to whole disk methods and disk partition methods, that existed in so called Jurassic era ;) , I reckon its more easier to recover compared to VXVMâ . I'm in the no process of inflicting any harm to VXVM. I love VXVM for its flexibility that it provides in the enterprise environment. I love VXVM in its own right and am a big fan of its technological capacities in the Volume management environment.

So let me stop bugging you with the boring introduction and get ahead with what I attempted to do, so here on it will get more technicalâ ¦ Please go through the attached DOC.

[Thayanidhi]

Hi,
The procedure looks fine. If you repeat same commands (which were used initially) you should get your data back.
E.g. when you create VG, ensure same PE size defined.

Best regards
TT

[Steven E. Protter]

Shalom senthil

Even if you run pvremove on a physical volume, its usually possible to run vgconfigrestore on the same physical volume and recover the configuration and probably not even necessary to restore the data.

Your outcome may vary.

Please take the time to publish your results and issues when the testing is complete.

Having read your document, I would expect the outcome that the document predicts. My suggestion above may be able to speed the recovery process, but I can see why you'd want to do it your way.

SEP

[Thayanidhi]

Hi SEP,

I am not too sure LV to PE layout will be retained while doing "vgcfgrestore"?
In his example each LV's PE are not contiguous.

Regds
TT

[Senthil Kumar .A_1]

Hi Guys,

Thanx for reading my thread. I hope it helps.

SEP : Just wondering one thing, though I haven't tried. I do agree you can use vgcfgrestore command because still the /etc/lvmconf/vg01.conf will be intact after removing the VG. But not too sure whether the sytem will accept the cammand for that VG, because it is no more in /etc/lvmtab right. But, any I will try steve's option.

PS: great guys, You are giving me different scenarios to work, I started liking LVM even more. ;)

[Senthil Kumar .A_1]

Hi SEP,



This is the error message I got,

vgcfgrestore -f ./vg01.conf.old /dev/rdsk/c4t0d1
vgcfgrestore: Volume group "/dev/vg01" does not exist in the "/etc/lvmtab" file.
vgcfgrestore: Invalid LVMREC on Physical Volume /dev/rdsk/c4t0d1

[Devender Khatana]

Hi Senthil,

The test is quite good and you are lucky to have some test servers with you. Allthough some more precautions should be taken in the commands used for recovery. The test scenario may not work with these commands if you recover the disk in some other system reason being -

The default PE size for different version of OS may not be same and if the vgcreate is not done having define the PE_Size, the contents might be lost. So a good choice in my opinion will be to specify the PE_Size as found in old vgdisplay output. Another option to verify the default PE_Size will be to use vgcreate on some other unused disk and see the PE_Size.

vgcfgrestore will not work as the VG does not exist in the system. Also vgcfgrestore will create LVM structure on the disk as per the properties of the VG where you are putting that disk in. Again if the PE_Size and offcourse the file system layout of the old disk differes the contents will be overwritten and will not be recoverable.

Do keep the results posted and the errors encountered?

HTH,
Devender

[Mridul Shrivastava]

As per my understaing whole information should match with the old VG (ie PE_size as mentioned by Devendar, max PEs, max VGs, allocation policy) all these parameters must be same for both vgs only then u'll be able to recover the data if mapping is correct.

[Kent Ostby]

Senthil --

That is a good looking document. When LVM was first new to the world, there were multiple similar documents that were passed from email to email within the Response Center and within HP's internal database.

For the most part, the focus these days has been on vgcfgrestore and other more standard tools, but it never hurts to have the brute force documented someplace handy.

[Senthil Kumar .A_1]

I hope this document Helped,

I can see from the response that, It could help in some ways in unusual situations.

:)

Senthil Kumar .A