This all started when a disk I use for archiving some data suddenly didn't mount anymore.When I tried with terminal, is said:The filesystem size (acording to the superblock) is 732566128 blocksThe physical size of the device is 732565864 blocksEither the superblock or the partition table is likely to be corrupt!When I try to mount it with the Gnome-Disk-Utility, I got this error:Error mounting /dev/dm-6 at /media/user1/3PAB:Command-line `mount -t ext3 -o uhelper=udisks2,nodev,nosuid /dev/dm-6 /media/user1/3PAB' exited with non-zero exit status 32:mount: wrong fs type, bad option, bad superblock on /dev/mapper/luks-c4ebeef5-7537-417e-b63b-fedc99561677, missing codepage or helper program, or other errorIn some cases useful info is found in syslog - trydmesg | tail or so.(udisks-error-quark, 0)Also, syslog gave me this:Dec 12 15:12:44 d8d kernel: [ 47.862779] EXT4-fs (dm-6): mounting ext3 file system using the ext4 subsystemDec 12 15:12:44 d8d kernel: [ 47.863025] EXT4-fs (dm-6): bad geometry: block count 732566128 exceeds size of device (732565864 blocks)I don't understand why it says mounting ext3 file system using the ext4 subsystem, when I know it's ext3 and lsblk -f confirms it.Although fdisk states Microsoft basic data but I already searched google and know this is a bug.I've tried fsck and fsck -f more than once both, but no luck.When I bought this disk, I actually bought two units (same size, same brand, etc), and formatted both the same exact way, and encrypted both of them with LUKS also the same.Only the data I put into each of them was different.So, after googling for some time, I ran this commands in both disks so I could see the differences and save all the results into txt files in case to be needed:sfdisk -luS /dev/sdgfdisk -l /dev/sdgtune2fs -l /dev/mapper/PABAs a result, I found that the superblock size was correct, so I concluded the partition of the first disk misteriously changed to some blocks early thus creating this situation.Device     Start        End    Sectors/dev/sdb1   2048 5860533134 5860531087 (correct; disk 2)/dev/sdg1   2048 5860531021 5860528974 (incorrect; disk 1)So, I  thought I could solve this by manually creating a new partition table using parted and set the end at the correct sector.I did that, but now the new partition isn't recognized as a LUKS partition.And in order not to make things worse than they are, I made this help request.Is it possible to recover the data?ADDING TESTDISK LOG:/dev/sdg: LBA, HPA, LBA48, DCO support/dev/sdg: size       5860531055 sectors/dev/sdg: user_max   5860531055 sectors/dev/sdg: native_max 5860533168 sectors/dev/sdg: dco        5860533168 sectorsUsing locale 'en_US.UTF-8'.  Wed Dec 14 01:02:53 2016Command line: TestDisk /debug /log /dev/sdg  TestDisk 6.14, Data Recovery Utility, July 2013OS: Linux, kernel 3.16.0-4-amd64 (#1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)) x86_64Compiler: GCC 4.9Compilation date: 2014-10-19T15:35:24ext2fs lib: 1.42.12, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: noneHard disk listDisk /dev/sdg - 3000 GB / 2794 GiB - CHS 364801 255 63, sector size=512 - ST3000DM001-1CH166, S/N:Z1F0R2CP, FW:CC43/dev/sdg: Host Protected Area (HPA) present.Partition table type (auto): EFI GPTDisk /dev/sdg - 3000 GB / 2794 GiB - ST3000DM001-1CH166Partition table type: EFI GPTAnalyse Disk /dev/sdg - 3000 GB / 2794 GiB - CHS 364801 255 63hdr_size=92hdr_lba_self=1hdr_lba_alt=5860531054 (expected 5860531054)hdr_lba_start=34hdr_lba_end=5860531021hdr_lba_table=2hdr_entries=128hdr_entsz=128Current partition structure:1   P   Unknown       2048  5860531021    5860528974    [PABnew]  
Need help recovering LUKS partition
luks