cgsecurity.org

There was a LVM with VG on two partition-based PVs

My bad, everything following was happening on a mounted filesystem.

I've successfully added the third PV:
pvcreate /dev/sdc2

Successfully extended the VG:
vgextend vgstorage /dev/sdc2

Successfully extended the LV:
lvextend -r -l +100%FREE /dev/vgstorage/lvstorage

There was a power failure one or two hours after extension and after that the filesystem is currupted.

dmesg | grep dm-4
[ 7.705752] EXT4-fs (dm-4): VFS: Found ext4 filesystem with invalid superblock checksum. Run e2fsck?

I've tried:
e2fsck /dev/dm-4
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_open2: Superblock checksum does not match superblock
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Superblock checksum does not match superblock while trying to open /dev/dm-4

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

Suggested superblocks here didn't work either.

Testdisk suggests >[ None ] as "None partition table type has been detected."
under >[ Superblocks ] it displays the following:

Disk /dev/mapper/vgstorage-lvstorage - 35 TB / 32 TiB - 70219857920 sectors

Partition Start End Size in sectors

ext4 0 70219857919 70219857920
superblock 0, blocksize=4096 []
ext4 262144 70220120063 70219857920
superblock 0, blocksize=4096 []
ext4 786432 70220644351 70219857920
superblock 0, blocksize=4096 []
ext4 1310720 70221168639 70219857920
superblock 0, blocksize=4096 []
ext4 1835008 70221692927 70219857920
superblock 0, blocksize=4096 []
ext4 2359296 70222217215 70219857920
superblock 0, blocksize=4096 []
ext4 6553600 70226411519 70219857920
superblock 0, blocksize=4096 []
ext4 7077888 70226935807 70219857920
superblock 0, blocksize=4096 []
ext4 12845056 70232702975 70219857920
superblock 0, blocksize=4096 []
ext4 21233664 70241091583 70219857920
superblock 0, blocksize=4096 []

To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device
enter code here

I'm not doing anything with that, as the data loss is much more critical than time to resolve the issue.
Can the advised command do more harm to the data?

I am missing the experience and detailed knowledge with ext4.
Duplicate your disk(s) before modifying anything including file system checks.

Unfortunately, unable to get another 2*18 + 6 TB drives for that