Your data beyond the first 300 MB or so is still recoverable, but you must be very careful on how to proceed. In particular, you'll want to minimize how much you write to this disk and save all your data that's recoverable elsewhere for a later reinstall. Luckily, you have an EFI partition that is greater than 300 MB at the beginning of the disk so the main OS partition may be untouched and 100% recoverable. In this case, you may just need to reformat the EFI partition and reinstall the bootloader.
First, as @Ponjar discussed, you need to fix the partition tables. The commands you ran only show the existing partition tables as they were found. Ignore the MBR partition table. That comes from the ISO image you wrote to the start of the disk and is incorrect. Instead, you need to restore a copy of the GPT partition table that the first command detected. Luckily, GPT stores a backup copy of the whole partition table at the end of the disk and gdisk is able to successfully read it. You will need to follow a procedure similar to this to recover the backup GPT:
gdisk shell will open now. Enter 'r' to select recovery option.
From the recovery option, enter 'b', to recover GPT header from secondary (backup), and then enter 'c' to recover GPT partition table from secondary (backup).
Then select 'v', and then 'w' to verify, and write to disk.
# sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): r
Recovery/transformation command (? for help): b
Recovery/transformation command (? for help): c
Warning! This will probably do weird things if you've converted an MBR to
GPT form and haven't yet saved the GPT! Proceed? (Y/N): Y
Recovery/transformation command (? for help): v
No problems found. 3437 free sectors (1.7 MiB) available in 2
segments, the largest of which is 2014 (1007.0 KiB) in size.
Recovery/transformation command (? for help): w
Once you have the partition table recovered, you will then need to recover the main OS file system. If it's true that the dd never reached this partition, then there may not be much more to do. Try mounting it on your recovery image:
sudo mount -r /dev/sda2 /mnt
I recommend using -r here for a read-only mount while checking for data. If it mounts and you see all your data present, it may be good for reusing without a reinstall. If everything is intact, you may be able to fix boot by just reinstalling the EFI system partition. That will need to be reformatted from scratch:
sudo mkfs -t fat -F 32 /dev/sda1
You will also need to make your root filesystem read-write:
sudo mount -o remount,rw /mnt
Then follow this guide to reinstall GRUB on the EFI system partition:
sudo mount /dev/sda1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sda
update-grub
However, if you found that you are unable to mount the root file system, you might have some small amount of data loss and will need to recover the superblock on your root filesystem. Based on the partition table and file size you mentioned in the question, this should not be the case, but if it is, this procedure should help find the superblock. Run mkfs -n on your root filesystem to discover where backup superblocks might be.
sudo mkfs -t ext4 -n /dev/sda2
The first few superblocks might be overwritten, but later superblocks should be intact. Based on the superblocks it showed, you can try and mount one with this:
sudo mount -o sb=131072 -r /dev/sda2 /mnt
Assuming that 131072 is one of the superblocks proposed by mkfs and hasn't been overwritten. If the data under /mnt looks reasonable and you are able to find some files, you can attempt to repair the file system with this:
sudo fsck -t ext4 -b 131072 /dev/sda2
However, at the point you are resorting to using alternate superblocks, you will probably want to backup any data you can save and do a full reinstall afterwards.
