Recovering lost lvol information?

[Joe Short]

I have a client who is building an MCSG/Oracle RAC cluster. The shared databases are on RAW. Today, the RAW lvols on one of the servers of the servers dissapeared. The lvols are still there, just the rlvols are gone. Is there a simple command that can be used to recover these rlvols?

[Michael Tully]

You could try to get it back using 'vgcfgrestore', but the best suggestion is to recover them from backup tape. See the vgcfgrestore man page

[Joe Short]

I know I can always use the map files I created to completely recreate the volume group.The problem is, I'm going to be tied up with another client on Wednesday, and all of the steps needed for a vgimport are too complicated for this client. I was hoping for something quick and easy that I could tell them to try.

[Michael Tully]

There is no real simple solution. Besides I would not want a client of mine fooling around with something as vital as this.

Have a look at this similar problem and decide for yourself whether it is easy enough. Again it is not something I would recommend.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=620723

[Hein van den Heuvel]

Do I understand you correctly that the lvol is still there, the data is still there?
So of the VG is called vgx and the lvol lvx then you do have /dev/vgx/lvx, but do not have /dev/vgx/rlvx due to an operational error perhaps. Well in that case I think you can just do a mknod using the major and minor number from the lvx.

For example:


[/usr/hein]$ ls -l /dev/*06*/*hein*
brw-r----- 1 root sys 64 0x060003 Jul 20 17:18 /dev/vg_xp06/hein
crw-r----- 1 root sys 64 0x060003 Jul 20 17:11 /dev/vg_xp06/rhein

time dd if=/dev/vg_xp06/rhein bs=1024k | grep -c hein
320+0 records in
320+0 records out
$ rm /dev/vg_xp06/rhein
$ dd if=/dev/vg_xp06/rhein bs=1024k | grep -c hein
/dev/vg_xp06/rhein: No such file or directory
dd: cannot open /dev/vg_xp06/rhein
real 0.0
user 0.0
sys 0.0
0
$ mknod /dev/vg_xp06/rhein b 64 0x060003
$ dd if=/dev/vg_xp06/rhein bs=1024k | grep -c hein
320+0 records in
320+0 records out
299

hth,
Hein.

[Hein van den Heuvel]

Hmm,

I may have spoken too soon.

Cleaning up from my test makes lvm complain, and I notice a new lvol call xxx/rhein. Odd. Unfortunately it'll be a while before I can follow up I'm afraid, so go easy. (or don't go).

Also, if this is for an Oracle datafile, then you will also want to do a chmod and chown on the mknod result (if you go that route).

Hein.

[Hein van den Heuvel]

Ah, ok, I was a touch sloppy. The revoce procedure I outlined does work, but somehow I used mknod 'b' where I darn well knwo it should be 'c' for the raw device as per:

> crw-r----- 1 root sys 64 0x060003 Jul 20 17:11 /dev/vg_xp06/rhein

So the right recovery fro my example was:

$ mknod /dev/vg_xp06/rhein c 64 0x060003



by accidently using the 'b' I created an 'alias' LV which confused lvm of course.
I just used rm on the duplicate block device then created the character/raw device with mknod 'c' and, re-tested, lvchange -a n, lvremove. Clean.

See also 'man 1m mknod'

Btw... I should have known something was smelly because in actuallity I timed the grep and the timing matched a block device, not a raw device. Oh well, so much for trying to help in a hurry.

Cheers,
Hein.

[Joe Short]

Just to put an end to the story. I ended up returning to the client location, and completely recreating the volume groups involved from the map file I had created originally.
Thanky to everyone who responded.

Joe

[Fred.Wu]

use "mknod" to create new device files for these raw devices , the same major and minor number as that before.

[Wang Xueyan]

mknod /dev/vgname/rlvname 64 c 0x######

The number "0x######" is as same as the lvol device file.