Retrieve data from disk after dd

Question

On Linux laptop, I mistakenly entered the wrong main HDD name in a dd command sudo dd if=/path/to/clonezilla-iso-file of=/dev/sda status=progress (clonezilla ISO file was 306 MB).

[This is a more complete follow-up of my original post following @PonJar and @oldfred suggestions, plus other online suggestions.]

When I restart the laptop, I get a "No bootable device found". Even when trying to re-install Ubuntu I get a "This computer currently has no detected operating systems" and the only option is to install the OS while wiping all data on the disk.

I understand that (hopefully) part of the disk that was overwritten is not recoverable. But I would still love if I could at least access (retrieve or extract) whatever data is still there.

---

What I tried so far:

Using an Ubuntu 20.04 bootable USB, I selected the "Try Ubuntu" option. Through the terminal, I could not access any of my 'old' data (nothing under the home directory).

I tried sudo gdisk -l /dev/sda which gave the following output:

GPT fdisk (gdisk) version 1.0.5

Caution: invalid main GPT header, but valid backup; regenerating main header from backup!

Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options on the recovery & transformation menu to examine the two tables.

Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
    MBR: MBR only
    BSD: not present
    APM: not present
    GPT: damaged

Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recover of GPT data.)
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer:

There, I entered 2 and got this:

Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Model: TOSHIBA MQ04ABF1
Sector size (logical/physical): 512/4096 bytes
Disk identified (GUID): B8CE21AF-F666-9ADA-9B95B7FFACFD
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3437 sectors (1.5 MiB)

Number  Start (sector)    End (sector)     Size       Code  Name
  1            2048          1050623      512.0 MiB   EF00  EFI System Partition
  2         1050624       1953523711      931.0 GiB   8300

Then I tried sudo parted -l and got this:

Model: ATA TOSHIBA MQ04ABF1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End      Size    Type    File System   Flags
  1     32.8kB  321MB    321MB   Primary               boot, hidden

Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes.
Ignore/Cancel?

Here, not sure how (and if) I can proceed.

Finally, based on advice from other online blogs, I tried accessing the BIOS and under the "Security" tab, tried selecting the “Select an UEFI file as trusted for executing” but my hard disk was not listed (I only have 1 hard disk and nothing was listed).

Is there anything else I can try? Is it possible to access my hard disk as an external disk from another device? Any help will be great cause I am getting desperate to retrieve my data.

Answer 1

I don’t think you actually repaired your partition table. When you pressed 2 after gdisk -l you got to see how the disk would be using the backup partition table. According to the gdisk manual page there is a recovery menu where you can make use of the backup and fix the partition. The key extract is below:

The second gdisk menu is the recovery & transformation menu, which provides access to data recovery options and features related to the transformation of partitions between partitioning schemes (converting BSD disklabels into GPT partitions or creating hybrid MBRs, for instance). A few options on this menu duplicate functionality on the main menu, for the sake of convenience. The options on this menu are:

b

Rebuild GPT header from backup. You can use the backup GPT header to rebuild the main GPT header with this option. It's likely to be useful if your main GPT header was damaged or destroyed (say, by sloppy use of dd).

Use r from the main gdisk menu to get to the recovery menu. Good luck!

Answer 2

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.