LVM lvol device file overwritten

[Michael Urbanski_1]

Hi Team,
I'm wondering what the impact of writing over the /dev/vgxxx/lvol1 file would be. Can you just restore from a backup or must I do something else (import / export ?). The data in the file systems all appear ok and i can drill down and everything is still there. But I am afraid if a reboot happens, then my problem might show up.

[DCE]

You can either restore it, or if you know the major and minor numbers, recreate it.

[Chan 007]

Mic,

You can create the VG map file as long as the vg is active,

It created a map file and txt file,

By having that you can import the map file and get your data, as long as the PV is fine.

vgexport -p -v -s -m -f

On getting the file just cat both map and txt file.

Ensure that your lvs are there in map file.
Also you find 1st 2 lives with few hex/dec ..leave it as it is..

Check the txt file whihc have you PV information.

Then reboot it.

On case if the vgs are not mounting
vgchange -a y
vgimport -m /root/mapfile /dev/vgxxx
you find all back,
just mount

Enjoy..

Chan

[A. Clay Stephenson]

It all depends. If you actually wrote data to the raw device then you almost certainly corrupted the data. The exception would be if you happened to write to an area of the volume that was not yet in use by the filesystem and was not part of the filesystem metadata itself. If you simply removed the device node (or if the device node is now a regular file) then no harm is done --- as long as you recreate the device node before rebooting; it's only a little more difficult afterwards.

Do an ls -l /dev/vgxxx. You should instantly see the pattern for both the character and block device nodes associated with this VG.

e.g.
cd /dev/vgxxx
mknod rlvol1 c 64 0x020001
mknod lvol1 b 64 0x020001

The first 2 hex digits of the minor device number should match those of the group node. Almost always the lvol1's remaining digits are "0001" indicating the 1st LVOL in the VG but this is not necessarity the case.

[Sivakumar TS]

Hi,

As long as you know the major & minor numbers, you can create the device files with #mknod command.

otherwise you can do vgimport and get all lvols.

With Regards,

Siva.

[Devender Khatana]

Hi,

I would add one more thing. After adding the device file using mknod prior to reboot, unmount the LVOLs in the VG and do a
#vgchange -a n /dev/vgxx
#vgchange -a y /dev/vgxx
#mountall

This will confirm wheather your file system will mount or not after reboot. This will be quite useful if the device file deleted belongs to /dev/vg00 volume group. In that case you off course can not unmount all LVOLs but can can try unmounting and mounting only one LVOL.

HTH,
Devender

[Michael Urbanski_1]

Team,

I appreciate the help offered from all of you. so far it looks like the DB FS is OK. The super blocks are giving some errors but I am told that an FSCK will fix those.It appears Oracle has security which did not allow the data to be written which would overlay the data that was already in the FS/ Directories. I hope the DBA's are correct in this because a 70gb recovery would not be pretty. So far it looks like Clay Stephenson's response was the closest to the actual issue (although his was the most scarey).

[Devender Khatana]

Hi,

Oracle security will not come into picture when you are writing data one level below file system level. It is surely a corruption of data and will cause problems in remounting the LVOL. I would suggest to backup data of this LVOL atleast before unmounting this LVOL and then try fsck which I am not quite sure will be able to fix it. If metadata is overwritten the data backed up will be fine and recreating and restoring will be able to fix it. If some part of data has also been overwritten then probably you will have to make use of previous backup of this LVOL.

HTH,
Devender

[Michael Urbanski_1]

Yes I think the same thing and we have done the backups and will again before the fsck takes place. Does your response mean the DBA's were not effeectively testing whether the DB is OK?

[Devender Khatana]

Hi Again,

It is not the case here. They may be very well verying the database but one can not say the status of the LVOL. The contents of the file system may be OK but you can not be sure unless you unmount and remount it.

HTH,
Devender