You are not logged in.
- Topics: Active | Unanswered
#1 2022-10-31 18:16:43
- Kundun
- Member
- Registered: 2020-03-30
- Posts: 9
Recover data after ext4 filesystem corruption
Hi everyone,
it appears that my main installation partition is corrupted (EFI partition and SWAP are fine and properly recognized).
I've already tried to follow dozens of guides (and posts from this forum) but nothing worked for now and I've come to the conclusion that:
1. My installation is broken and the best solution is to just start over with a new one.
2. My data are probably lost but maybe with some effort I can recover a part of it.
Let's focus on the second point since the first one is pretty straight-forward.
Most of the guides suggest that this situation is caused by a broken drive but I don't think this is the case (I'm using a two years old WD NVMe SSD), I'm pretty sure the filesystem just ended up corrupted via the system. The possible broken drive issue is not relevant tough, at the moment I just want to recover the data (or part of it) if it's possible.
My ext4 filesystem seems to be broken (it isn't even recognized as ext4 by GParted via GParted Live, while parted doesn't display a partition table at all) and it has tons of bad blocks, so I've tried several methodologies to fix it (fsck and e2fsck with alternative superblocks, etc) but nothing worked so far.
I've tried to use testdisk but I haven't read its documentation in proper depth yet, so if anyone has advices on that I'd really appreciate it.
I know that in order to have a 1:1 copy of the partition I have to use ddrescue, but I don't know where to go after that (the filesystem will still be broken, right?). What can I do with its image to recover data or a file structure? I'm reluctant to "just run it" since the backup will take 14 hours.
It would be great to recover the data but even a file tree would be enough to not consider the whole situation a complete disaster.
I know that I'm being very generic, but any advices or heuristics are welcome.
Thank you for your attention and your time!
Offline
#2 2022-10-31 20:42:01
- Lin0x
- Member
- Registered: 2022-10-31
- Posts: 2
Re: Recover data after ext4 filesystem corruption
I would mount the HD on another working system, and copy all critical data out of it. Never run fsck.ext4 or e2fsck because it might get it unusable. Done that in the past, just broke the ext4 even more. Had to testdisk it and it took months.
Offline
#3 2022-10-31 21:50:54
- seth
- Member
- From: Won't reply 2 private help req
- Registered: 2012-09-03
- Posts: 76,446
Re: Recover data after ext4 filesystem corruption
The possible broken drive issue is not relevant tough
It is actually *very* relevant, since any writing attempts to a broken device would worsen the situation and
tons of bad blocks
sounds a lot like the disk is toast. Do under no circumstances try to write on it until you've recovered your data.
In this case of a broken disk you'll have to ddrescue the partition into an image on another drive, if the disk itself was fine and only the FS corrupt, the regular dd would do fine.
Once you have such image, you can make copies of it and experiment on those copies to resurrect the FS, but if the disk is broken and you can only recover fragments of the FS, you'll have to use testdisk & photorec to hopefully recover at least some data.
Offline
#4 2022-11-01 23:48:05
- Kundun
- Member
- Registered: 2020-03-30
- Posts: 9
Re: Recover data after ext4 filesystem corruption
I would mount the HD on another working system, and copy all critical data out of it.
Sadly when I try to mount the partition on GParted Live I get (even using alternative superblocks):
mount: /mnt: can't read superblock on /dev/nvme0n1p1.In this case of a broken disk you'll have to ddrescue the partition into an image on another drive [...]
I used ddrescue to create an image of the partition (it took 13.5 hours to clone a 500gb NVMe SSD to a USB3 HDD, just for the record), the following is the execution output:
sudo ddrescue -d -r3 -b4096 /dev/nvme0n1p1 /mnt/hdd/image /mnt/hdd/log
GNU ddrescue 1.26
Press Ctrl-C to interrupt
ipos: 494994 MB, non-trimmed: 9895 kB, current rate: 11141 kB/s
opos: 494994 MB, non-scraped: 0 B, average rate: 10455 kB/s
non-tried: 1424 MB, bad-sector: 0 B, error rate: 0 B/s
rescued: 493560 MB, bad areas: 0, run time: 13h 6m 43s
pct rescued: 99.71%, read errors: 151, remaining time: 2m 13s
time since last successful read: 0s
Copying non-tried blocks... Pass 1 (forwards)
ipos: 4456 kB, non-trimmed: 16646 kB, current rate: 14680 kB/s
opos: 4456 kB, non-scraped: 0 B, average rate: 10458 kB/s
non-tried: 1092 MB, bad-sector: 0 B, error rate: 589 kB/s
rescued: 493886 MB, bad areas: 0, run time: 13h 7m 2s
pct rescued: 99.77%, read errors: 254, remaining time: 1m 6s
time since last successful read: 0s
Copying non-tried blocks... Pass 2 (backwards)
ipos: 481404 MB, non-trimmed: 1082 MB, current rate: 0 B/s
opos: 481404 MB, non-scraped: 0 B, average rate: 10452 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 37486 kB/s
rescued: 493912 MB, bad areas: 0, run time: 13h 7m 33s
pct rescued: 99.78%, read errors: 16516, remaining time: 24m
time since last successful read: 2s
Copying non-tried blocks... Pass 5 (forwards)
ipos: 481404 MB, non-trimmed: 0 B, current rate: 2605 kB/s
opos: 481404 MB, non-scraped: 1077 MB, average rate: 10452 kB/s
non-tried: 0 B, bad-sector: 749568 B, error rate: 3915 kB/s
rescued: 493917 MB, bad areas: 180, run time: 13h 7m 34s
pct rescued: 99.78%, read errors: 16699, remaining time: 6m
time since last successful read: 0s
Trimming failed blocks... (forwards)
ipos: 481404 MB, non-trimmed: 0 B, current rate: 0 B/s
opos: 481404 MB, non-scraped: 0 B, average rate: 10352 kB/s
non-tried: 0 B, bad-sector: 1075 MB, error rate: 2375 kB/s
rescued: 493919 MB, bad areas: 252, run time: 13h 15m 9s
pct rescued: 99.78%, read errors: 279142, remaining time: 3d 3h 28m
time since last successful read: 27s
Scraping failed blocks... (forwards)
ipos: 481404 MB, non-trimmed: 0 B, current rate: 0 B/s
opos: 481404 MB, non-scraped: 0 B, average rate: 10255 kB/s
non-tried: 0 B, bad-sector: 1075 MB, error rate: 2383 kB/s
rescued: 493919 MB, bad areas: 252, run time: 13h 22m 42s
pct rescued: 99.78%, read errors: 541768, remaining time: n/a
time since last successful read: 8m
Retrying bad sectors... Retry 1 (forwards)
ipos: 0 B, non-trimmed: 0 B, current rate: 0 B/s
opos: 0 B, non-scraped: 0 B, average rate: 10159 kB/s
non-tried: 0 B, bad-sector: 1075 MB, error rate: 2383 kB/s
rescued: 493919 MB, bad areas: 252, run time: 13h 30m 16s
pct rescued: 99.78%, read errors: 804394, remaining time: n/a
time since last successful read: 15m 34s
Retrying bad sectors... Retry 2 (backwards)
ipos: 481404 MB, non-trimmed: 0 B, current rate: 0 B/s
opos: 481404 MB, non-scraped: 0 B, average rate: 10065 kB/s
non-tried: 0 B, bad-sector: 1075 MB, error rate: 1789 kB/s
rescued: 493919 MB, bad areas: 252, run time: 13h 37m 48s
pct rescued: 99.78%, read errors: 1067020, remaining time: n/a
time since last successful read: 23m 6s
Retrying bad sectors... Retry 3 (forwards)
Finished 99.78% of rescued data seems like a fair percentage to me, but maybe the corrupted gb was essential to the whole filesystem.
Tomorrow I'll try to use testdisk and photorec, just let me know if anything can be inferred from the stats above.
Offline