Do the fsck with an overlay in place.
I suspect the data in the inodes will provide corroboration for newer
data in the various structures. I think your odds are good, now.
On 9/10/22 16:12, Luigi Fabio wrote:
Following up, I found:
The backup ext4 superblocks are never updated by the kernel, only after
a successful e2fsck, tune2fs, resize2fs, or other userspace operation.
This avoids clobbering the backups with bad data if the kernel has a bug
or device error (e.g. bad cable, HBA, etc).
So therefore, if we restore a backup superblock (and its attendant
data) what happens to any FS structure that was written to *after*
that time? That is to say, in this case, after Aug 18th?
Is the system 'smart enough' to do something or will I have a big fat
mess? I mean, reversion to 08/18 would be great, but I can't imagine
that the FS can do that, it would have to have copies of every inode.
This does explain how I get so many errors when fsck grabs the backup
superblock... the RAID part we solved just fine, it's the rest we have
to deal with.
Ideas are welcome.
