0

I have an LVM drive & filesystem made up of 4 disks. One of them has had a hardware failure and doesn't work anymore. When this happeend some of the files were readable on the filesystem, and some gave errors. I have rebooted the machine and now the (broken) filesystem (it's ext4) doesn't mount at all. I have run fsck/e2fsck on the device (/dev/volgroupname/lvname). I have taken out the bad disk, and put in a brand new disk of the same capacity, and add that as PVs to the VG.

Is there anyway I can recover as much data as possible from it?

Each of the PVs was ~500GB, so maybe there's some chunks of data there that I can recover?

(Yes I know I should have backups, or use a real raid set up, but these files aren't critical, but I'd like to get as many as possible back)

mount reports:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/volgroup_lvname,
       missing codepage or helper program, or other error

with dmesg:

[62004.117164] EXT4-fs (dm-9): bad geometry: block count 967555072 exceeds size of device (478894080 blocks)
Amandasaurus
  • 30,211
  • 62
  • 184
  • 246
  • 1
    Aw man, that was always my nightmare, that's why I'm super paranoid even with uncritical data... How were the PVs set up? I guess you didn't use the striping option? If you did, your data is definitely gone and your only chance is professional data recovery (they replace broken parts within the drive to make the hardware function again). If you didn't use striping, you can restore the vg by replacing the disk and copying the LVM metadata. Never had to do this myself but I read about it here https://www.novell.com/coolsolutions/appnote/19386.html I wish you the best of luck – Broco Nov 22 '19 at 14:53

1 Answers1

2

I strongly suggest using ddrescue to take a copy of each component disk and running testdisk/photorec on the copied images.

Alternatively you can try to: - mount the filesystem via a backup superblock - use fsck.ext4 to repair the filesystem. Note: this will not really repair the filesystem, as an entire device failed. However it has a chance to repair the superblock and some directory metadata.

Anyway, fiddling with a broken filesystem is a dangerous game as you risk to amplify the already existing corruption. Hence my suggestion to take a binary image of each disk.

shodanshok
  • 44,038
  • 6
  • 98
  • 162
  • Can you explain how to “try using fsck.ext4 to mount the filesystem with a backup superblock copy”? I've never done that before. When you say ”this will alter the data” can you explain _how_ much data? Since some disks are gone, some data will be lost, is that what you mean? Or do you mean “nearly all data” would be gone? – Amandasaurus Nov 23 '19 at 09:58
  • @Rory I clarified my answer. Regarding which data can be affected by your recovery attempts, please note that nobody can precisely answer you. In these cases the golden rule is to take a binary image of the disk *before* attempting recover. – shodanshok Nov 23 '19 at 11:22