Corrupted ext4 disk with windows disk manager

I am the main linux person in our team (which is a sad state of affairs), and am trying to fix a problem created by one of our windows users.

They had a 5TB drive with a single ~5TB ext4 partition with a bunch of video files. They weren’t the one who set up the drive, so when they couldn’t access it in windows they went into disk manager and ” converted to GPT” in windows disk manager. Now it isn’t accessible in ubuntu either.

Disk: Seagate ST5000DM

fdisk reports: the wrong disk size

Disk /dev/sdg: 561.5 GiB, 602934566912 bytes, 1177606576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa6985519

Testdisk reports the wrong disk size: >Disk /dev/sdg – 602 GB / 561 GiB – ST5000DM 000-1FK178

fsck reports:

fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks…
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdg

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
e2fsck -b 32768

Found a PMBR partition table in /dev/sdg

Gdisk reports:
Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header’s self-pointer indicates that it doesn’t reside
at the end of the disk. If you’ve added a disk to a RAID array, use the ‘e’
option on the experts’ menu to adjust the secondary header’s and partition
table’s locations.

Problem: Disk is too small to hold all the data!
(Disk size is 1177606576 sectors, needs to be 9767541168 sectors.)
The ‘e’ option on the experts’ menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 9767541134, but backup header is at
9767541167 and disk size is 1177606576 sectors.
The ‘e’ option on the experts’ menu will probably fix this problem

Problem: partition 1 is too big for the disk.

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Identified 6 problems!

File recovery programs can still read the files, so I can fall back on that if I have to, but it will take forever and lead to endless sorting and renaming of files. I am hoping I can ” fix” the partition table to be able to mount the drive and immediately back up the data onto a secure, backed up location.

Thanks for any assistance. Any guidance on what to try is appreciated. I haven’t had to deal with this kind of thing before, my linux usage is pretty vanilla.

Go to Source
Author: Chris Hall