fsck.ext4 zero-filled Files on a lvm-partition because of dying drive
 

Hello,

I did a fsck.ext4 on a unmountet filesystem: After this the files had the right size, names and even the right rights and ownerships!

The only problem is, that those files have all been zero-filled by fsck, so they are now useless...

I checked many files with a Hex-Editor and every larger file has only zeros as "data".

So my question is now: Is there some way to "undo" the fsck?

Can i repair the fs by using the journal and backup-superblock (i´m not sure how to this correct right now, either by using fsck options i didn´t read yet, or by using file-carvers like ext4magic, testdisk/photorec, scalpel).

Best Regards

DrBenzo

push

fsck doesn't "zero-fill". Ever.

What it does is repair pointers to damaged blocks.

What very likely happened is that the damaged blocks could not be read to be relocated by the drive - but fsck forced the pointers to blocks, which were likely already zero filled.

Alternatively (and it depends on the filesystem and driver) fsck didn't zero fill, but left holes in the file for the damaged blocks. Such holes are always filled with null pages in memory when read.

Exactly which scenario occurred can be identified by a file system debugger. Holes in file (also referred to as "sparse file allocations") will be identified by missing metadata pointers. The file size information is stored in the inode, but bad blocks removed by the driver will not be identified.

But there is little chance of recovery from a failing disk.

Nope.
The journal has already been run, and all the superblocks would have been "cleaned". I've never seen what you describe, but I agree with @jpollard that sparse files looks a good bet - would explain the apparent zero data.

Some of the forensics tools might help, but they are slooooooow, and can (do) result in partial files in extreme situations. fsck is designed to recover the integrity of the filesystem itself - backups are for data.

Thanks for reply!

There are not only holes in the files, the files are one big "black hole" whithout any data left. Before i ran fsck i could read many of the files without problems. After the fsck run there where ~1TB of empty files, can this be done with what you described?

A failing disk can result in lots of things.

Very likely that is what is happening.

If you have a head crash, you tend to only have one chance at retrieving data - That is because of damage to the read head causing damage to the disk as it reads... Thus a second read gets nothing.

I was able to recover data ONCE in such a situation - I copied the disk, but in the process scraped off nearly all the oxide from the disk being read. This was a LONG time ago when "removable packs" were cheaper than a whole drive, and drives were the size of washing machines.

My last attempt was a 2TB disk starting to go bad... Didn't get much at all.