Topic: Data rescue after interupted move and resize of EXT4 partition

I decided to clean up my laptop hard drive. I skip a few steps that went fine. Where my problem started was at this stage:
1: bios 500 mb
2: Linux system 70 gb
3: empty space ~300 gb
4: linux home (ext4) ~600gb
5-8: Old unused windows /OEM backup and service drives ~30 gb

From this stage I wanted to get to
1: bios 500 mb
2: Linux system 70 gb
3: linux home (ext4) ~929.5gb

This means I order gparted to move partition 4 to the end of partition 2 and grow it to the end of the 1TB hard drive.
I performed the process from a usb thumbdrive and it was supposed to take around 1:20. Unfortunately, the OS on the thumbdrive went into suspend mode and when i came back after around 2 hrs it didn't wake up hmm . I waited another 3 hrs with silent hope that the process would finish in the back ground, but it didnt.
After restarting the laptop, the linux home partition is unreadable. Clearly, the process got interrupted somewhere along the way. Gparted can see a ext4 partition that has 930 gb in size with around 300 gb of unallocated space and recommends that I grow that partition.

I was able to use dd_rescue to make a copy of the entire drive and saved it to a disk image (.img) on an external drive.

Before I do anything wrong with the original harddrive, I wanted to ask about the smartest way to move forward from this point.

I have a recent backup, but unfortunately it doesnt include some work from the last days and a lot of the .config/.local, etc files from the home folder. I would be keen to reconstruct the drive, rather than just use the backup.

Thanks for any help.


Re: Data rescue after interupted move and resize of EXT4 partition

Situation analysis
So your operation on partition 4 linux home (ext4) was approximately:
Move start to the left by 300 GiB, grow to the right to fill the drive.

GParted will perform this combined move left and grow operation in 2 phases:
1.  Move the partition and file system contents to the left by 300 GiB.
2.  Grow the partition and file system to the end of the drive.

Step 1 involves copying the contents of the ~600 GiB file system over the top of itself, ~300 GiB to the left.  After starting, this is what GParted is able to estimate as would take 1h20m.  Failure in this step can lead to not being able to recognise a file system any more and even leave the file system partially overwritten.

Step 2 only involves growing the file system which is usually quick and on failure doesn't usually lead to loss of identification.

Recovery suggestions
I assume the operation stopped in step 1 because that takes longer and is more likely to lead to inability to identify the file system.

1.  Assuming you know the old boundary for partition 4 (to the sector) from before you started, and that step 1 hadn't got as far through the
   copy as to be overwriting the file system yet, then:
1.1. Create a loop device covering where partition 4 use to be.
1.2. Mount it read-only and see if it works.

2. If you don't know the old partition 4 boundary, but assuming that step 1 hadn't gotten as far as overwriting the file system yet then:
2.1. Try testdisk to find the old file system.  (GParted Manual / Recovering Partition Tables).

3. Try photorec to recover recognised file data from blocks on the hard drive.

4. Restore from backup and re-create data lost since the last backup.