-1

I recently resized one partition inside an LVM on my disk using gparted. No errors were given, but now the filesystem is corrupted and I'm trying to recover it.

When I mount it, no errors appear but when I ls into the mount point I have a directory full of files/directories with broken attributes that give input/output error. To be more explicit, all files have a random name except for one detail, a dot always in the same position. For example, these are two of the file names: ?enOxfJl.mul, FMgUIKEJ.ahg.

I suspect there's some "shift" in the filesystem, also because one of the files is named -----BEG.IN, that looks exactly like the beginning of a PGP message, and I actually have some of them in that partition.

I already used PhotoRec to recover readable files and it seems that nothing is really lost, I recovered quite everything but that software cannot restore also the directory tree.

I wonder if there are some kind of tricky mount options to read again the filesystem without recreating it, or simply some software to repair that broken fs. I already tried TestDisk, but it seems more appropriate for restoring broken partition tables than filesystems

1 Answer 1

1
  1. Find the relevant VG config backup. On this machine I'm on now (Debian 9), VG config backups get written to /etc/lvm/archive/. Helpfully, each backup contains a description of the command that was run, so it shouldn't be too hard to figure out which one it was.
  2. Use vgcfgrestore to put the old VG config back in place.
  3. Assuming you didn't screw up the filesystem with your previous attempts to fix it, it should mount now.
  4. Setup a decent backup regime.

If gparted doesn't create VG backup files, then chalk whole episode up as a learning experience, both in why backups are rather important, as well as why gparted is a steaming pile that should be avoided at all possible costs.

3
  • - I have a backup, I want to restore the partition as a challenge to learn something because I saw that strange name pattern of the files. - Unfortunately, I don't even have a /etc/lvm/archive, so I think gparted didn't save any history of the resize. Dec 30, 2018 at 11:14
  • You say that gparted should be avoided at all costs, but can you tell me the reason? Dec 30, 2018 at 11:20
  • Well, the fact that it doesn't keep backups of VG metadata would be enough by itself.
    – womble
    Jan 2, 2019 at 22:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.