Re: Restore deleted /dev/vgxxx

SOLVED

A volume directory structure was deleted (/dev/vgxx) and the volume is still mounted.

How do we restore the /dev/vgxx directory structure?

20 REPLIES 20

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

Anyone for a Mutiny ?

From the /etc/fstab, you can find out the lvols you need. Or from your mnttab (run the mount command).

As for the group file, that's more difficult. But what you need to do:
1) create the directory /dev/vgxx
2) create the group file using mknod:
mknod /dev/vgxx/group c 64 0x0000
3) create the lvol device files
mknod /dev/vgxx/ b 64 0x00
mknod /dev/vgxx/r c 64 0x00

The difficulty in all this is to get the groupid and lvolid. But I think you can get the lvolid's from your mapfiles in /etc/lvmconf.

Every problem has at least one solution. Only some solutions are harder to find.

Hi,
I assume you have map file of the vgxx and if not try searching for one. Also try remembering the group file minor no., you can judge it looking at other VG's group file. Then this should work.

1. # mkdir /dev/vgxx
2. # mknod /dev/vgxx/group c 64 minorno.
3. # vgimport -v -m vg01.map /dev/vgxx

Hope that helps.
Regards,

You need to know a lot to actually know how little you know

vg01.map .. i mean vgxx.map Regards,

You need to know a lot to actually know how little you know

no .map , but the config file is in the /etc/lvmconf/vgxx

I had already recreated the files (/dev/vgxx/group , lvol1 , rlvol1) using mknod and since there is only one lvol, that part was a slam dunk... BUT, what I didn't know "for sure" was the group file number or how to extract it.

hi,
Group is control file for VG and look like this :
crw-r----- 1 root sys 64 0x000000 Feb 3 06:07 group

it resides in /dev/vgxx

0x stands for hex no.
00 stand's unique group number.
0000 (last 4) are always zero.

Noramlly group no. are 01,02 ..

Hope that helps.
Regards,

You need to know a lot to actually know how little you know

I'm already aware of how the numbering works, I just didn't know how to retrieve the number, I looked at the other vol groups and have guessed that this one would be #2, ie: 0x020000 , and the lvol1 files 0x020001.

But until I get the tapes back on-site, this is just a guess.

Kim

You could vgimport the disks.

Create the volumegroup.
# mkdir /dev/vgxx
# mknod /dev/vgxx/group c 64 minorno

Preview
# vgimport -p -
v /dev/vg01 /dev/dsk/c0t1d0 /dev/dsk/c0t3d0

# vgimport -v /dev/vg01 /dev/dsk/c0t1d0 /dev/dsk/c0t3

# vgchange -a y vg01

Regards,
Robert-Jan

Tried vgimport last night... just comes back and says that it's already in the lvmtab. Even tried moving the lvmtab to a different name and tried it, It just recreated the new lvmtab, but didn't recreate the files in /dev/vgxx.

I thought that was strange, so I imported a volume from a different system and the files were created as expected.

I suspect that if I were to unmount the volume and vgimport it, the files would be recreated, but unmounting it isn't an option on this system (production - not many opportunities to do that).

I think what you need is group minor no.
don't you?
correct me if I am wrong..

mknod /dev/vgxx/group c 64 0x0y0000

y will be 01 if it is vg01
y will be 02 if it is vg02

Anil

There is no substitute to HARDWORK

When volumes come and go, and the volume names aren't always vg01, 02, etc. , life isn't always so simple. Some volumes are named to be a bit more descriptive of what they actually are.

Like vgemc1db1, or vgemc2db1, or vgdbora, etc.

In this situation, finding what the group number was is what I was looking for, to see if it is buried somewhere that a scan could get it (0x0?0000).

strings /stand/vmunix | grep "your_vg_name"
It should be there somewhere.

Anil

There is no substitute to HARDWORK

Nope - none of the system's vg's information is available like that (at least not by vg name)

Another crude method.

ll /dev/vg??/group.

Check what have been used and any relation ship between the one used and their respective vg names. But this is not 100 % correct.

Anil

There is no substitute to HARDWORK

That's what I've done until I can get the tapes back on-site. That is why I said above... that is the one thing I'm "NOT SURE" about. I'm guessing, and I hate to guess about something liks that!

Hi Kim,

I just figured you might as well can give any free minor to the group file. But if the lvs are unmounted and if you try to mount them back, you will get "No such device or address" error message.

But if you deactivate the vg and activate again then there should be no issues.

As you said, you are not going to unmount the lvs anytime in the near future. If you had to , you can as well deactivate and activate the vg again ?

-- Sundar.

Learn What to do ,How to do and more importantly When to do ?

okay - restored the files from tape to a different temp directory.

I did use the correct vg numbers when recreating the vg files (0x020000), so I've left the files there that I created instead of overwriting them.

Now... will the vg's get mounted up without any further intervention next time I unmount or reboot the system?

hi,
# strings /etc/lvmtab

Do see your VG in this. If yes it is ok or else recreate lvmtab file using "vgscan -a" see man vgscan.

Update fstab file for all LV.

Regards,

You need to know a lot to actually know how little you know

Kim,

Yes, the VG should get activated without any need for manual intervention as long as you have the group control file and the character/block device files for all the logical volumes.

-- Sundar.

Learn What to do ,How to do and more importantly When to do ?

You can restore the lvm structure by doing

#vgcfgrestore vgxx

or

# vgchange -a y