Home / server / Questions / 626877
In Process
Vilx-
Asked: 2014-09-08 14:08:02 +0800 CST

How to recover data from a messed up drive (LVM written on top of Ext4)?

  • 772

The previous administrator of a server that is now under my supervision made a mistake. He accidentally created a LVM volume (no more than pvcreate, I think, though not sure) on a disk that actually contained an Ext4 partition with data. How do I recover data from a mistake like this? I'm ready to read ext4 documentation and roll out my own, but perhaps I don't need to? A few tools that I tried were unable to find an Ext4 filesystem on it, so I guess I need something more serious.

ext4

3 Answers

  1. If you run mkfs.ext4 -n /the/partition it will print out what a EXT4 formatted drive would look like on that system.

    # mkfs.ext4 -n /dev/dm-3
mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
3276800 inodes, 13107200 blocks
655360 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
400 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424

    Of note is that it will tell you where the superblock locations are.

    Using this information, attempt to mount the drive using an alternative superblock..

    mkdir /tmp/mntpnt
mount -o ro,sb=163840 /dev/dm-3 /tmp/mntpnt

    Providing only the headers of the partition were destroyed this may work.

    If that doesn't work however, you can try to fix the filesystem using fsck.ext4 by specifying the superblock address. Backup the data with dd or something before you do this.

    fsck.ext4 -b 163840 /dev/dm-3

    This may just end up overwriting the bad superblock with one of the known good ones, which could be enough to get the entire disk remounted. Then again you may lose key inodes (like your root filesystem inode). Mileage may vary.

    • 6

  2. I would give the UFS Explorer demo a try to see what it can detect... It's my go-to utility for filesystem recovery. I once had an XFS partition with 4 million files accidentally deleted and used this utility to recover the data.

    But outside of that, it's a learning experience and a chance to test your backup routine. Sorry for the loss.

    • 3

  3. The first step in any recovery operation is to make a copy of the data, and perform the recovery on the copy. Once you've done that, you can attempt to recover the data.

    Depending on what exactly the admin did, the most likely damage is that the partition table has been corrupted, the volume's primary superblock has been corrupted, or both. You can re-build the partition table using fdisk: simply create a new partition table with the same setup as the original. Make sure you get the type (MBR or GPT) right. e2fsck -b will let you perform a filesystem repair using one of the secondary copies of the superblock, or in the unlikely event that they've all been corrupted, mke2fs -S will re-create the metadata structure without touching the data.

    • 3