How do I recover files from ext4 with "discarded blocks" and rewritten superblock

Question

I have resized an ext4 partition using parted, and found online that, to resize it without data loss, I need to run mke2fs -S /dev/sdxx -t ext4 ; fsck.ext4 /dev/sdxx -p. I took a look at the commands and their man pages, and it seemed fine, since they said they only overwrite the superblock, without touching anything else or discard other blocks. However, this was the output:

mke2fs 1.45.5 (07-Jan-2020)
/dev/sda1 contains a ext4 file system
    last mounted on Mon Oct 11 10:56:46 2021
Proceed anyway? (y,N) y
Discarding device blocks: done                            
Creating filesystem with 7145382 4k blocks and 1787040 inodes
Filesystem UUID: 55863129-4a43-4b9c-82eb-4432b623e0d0
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000

Allocating group tables: done                            
/dev/sda1 may be further corrupted by superblock rewrite
Proceed anyway? (y,N) 

This was already really concerning, since it said it was "discarding blocks". Then, I ran the fsck command and its output contained

fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** journal has been deleted ***

and

Root inode is not a directory.  Clear<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Root inode not allocated.  Allocate<y>? yes

At this point, i pretty much knew the FS was doomed.

I'd really appreciate any advice. The most important documents are ODT files, so technically ZIP archives. I have already tried writing a small program to extract everything with a PK[3,4] header, but this failed because of how the file system's structured.

Answer 1

The resizing procedure you found seems very strange: blindly creating a new superblock on top of the old one is risky even if everything else about the filesystem remains the same, but seems incredibly unlikely to actually work if the filesystem's dimensions have changed – the new superblock will be expecting to find inodes and block groups at a completely different location; what it thinks is the "/" inode is probably some garbage data miles away from the real inode.

(Even the manual page notes about -S that "This is an extreme measure to be taken only in the very unlikely case that all [superblocks] are corrupted" and "there is no guarantee that any data will be salvageable".)

The correct procedure would've been to use the resize2fs program, which has been included in the same package as mkfs.ext4 and fsck.ext4 for more than two decades; it resizes and relocates the filesystem structures as necessary.

At this point, however, do not try to resize2fs a damaged filesystem or do anything else to it – instead run testdisk on it to scrape as many files as it can still find. Testdisk works pretty much like the program that you tried to write, only deals with more formats (not just zip).

However, if you have enough disk space to make an image of the damaged filesystem, you could try resizing the partition back to exactly its original size and using mkfs -S once more. (Do it on an image – after making the backup image!) This could actually end up with a superblock that has the same parameters as the original one, and hopefully point at the original data structures if those haven't been damaged yet.