0

Today I've plugged new ssd into my PC and started an dd command for USB drive. It was too late as I recognized, that the drive letters moved around and I started flashing an ISO image over all my data. I recognized it after 2 seconds and cancelled the process but it was already too late.

Do you think there is any chance of restoring the data? I ran it over a hard drive.

It's how it looks inside of fdisk:

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdd1  *        0 11311103 11311104  5.4G  0 Empty
/dev/sdd2         808     5427     4620  2.3M ef EFI (FAT-12/16/32) <- it was the NTFS partition with size of 991 GB

And this is output of /proc/partitions:

major minor      #blocks    name
   8    48     976762584    sdd
   8    49       5655552    sdd1
   8    50          2310    sdd2

This hard drive has a capacity of 1TB and it was formatted with NTFS. I've used it as storage for both - Linux and Windows.

The dd (dd ver: 9.1) command was fired from Fedora 37 and it was this one:

sudo dd if=./Qubes-R4.1.1-x86_64.iso of=/dev/sdd
Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
WinterMute
  • 1
  • 1
  • You have crushed the partition table and likely the file allocation table. Probably many files can be recovered, with usual recovery softwares (but without their names, without directory structure...). If you are very lucky and if you have stopped `dd` soon enough, maybe the file allocation table is still there : if so, you could just recreating the original partition, without formating it. If a filesystem can be mounted you win! In any case do not attempt any recovery that has to write on the disk without making a clone before that. – PierU Nov 29 '22 at 11:06
  • Please provide more details about how it was before. Which OS, which filesystems, which partitions? // It is important to not modify the disk any further so as not to jeopardize your chances of data recovery. // Fortunately, on a HDD, it only overwrite some low hundreds of megabytes in 2 seconds, so the outlook isn’t that bad. – Daniel B Nov 29 '22 at 12:15
  • Your description is too vague IMO. You partially overwrote a spinning HDD right? What partitions were on it previously (sizes = file systems)? – Joep van Steen Nov 29 '22 at 12:51
  • okay, maybe I didn't wrote it clear enough. Just like said, it was a FAT32 partition. I use it as storage for all my systems. Linux and windows. I've executed this command from fedora 37 – WinterMute Nov 29 '22 at 13:36
  • Sorry guys, my mistake... It is NOT FAT32, it was NTFS – WinterMute Nov 29 '22 at 14:40
  • AH YES, of course, duplicate, it was a matter of time before someone claimed it's a duplicate that's answered by the the rabbit hole wiki topic. Utter nonsense. – Joep van Steen Nov 29 '22 at 18:17
  • There are two kinds of people: those who make backups and those who will. Mistakes leading to data loss happen, just like hardware malfunctions, ransomware attacks and catastrophic bugs. Come up with a good backup strategy first thing after getting your data back. – gronostaj Nov 29 '22 at 19:17
  • @WinterMute - You should [edit] your question to resolve any disparities between the information you provided and what actually is reality – Ramhound Nov 30 '22 at 13:52

1 Answers1

1

Assuming approximately 1 TB FAT32 partition, start of volume overwritten, biggest determining factor is whether FATs (file allocation tables) ,or at least one copy survived. No one can tell this in advance as multiple variables are at play; how much was overwritten and size of FATs.

IF FAT survived file system based recovery is possible. This means we can reconstruct (virtually) a folder structure, recover file names, and recover fragmented files.

Without the FAT we can (partially) reconstruct folder structure and filenames but we'd have to assume all files are contiguous. So result of recovery is dictated by amount of data that was overwritten:

enter image description here

Ideally when dealing with data-loss scenarios you clone or image the patient drive first. So for that you'd need a destination drive with sufficient capacity.

I suggest then you scan the clone/disk image (or patient drive if you decide not to clone) using a tool like DMDE. After scan select most promising file system.

Then click 'All found / Virtual file system > Default reconstruction > Parameters to determine state of file allocation tables.

enter image description here

Select 2nd FAT if 1st is partially damaged.

DMDE demo allows you to test recovery by actually saving some files. You can also preview for example JPEG files. Check some larger JPEGs and see if the look okay. If not the tool may have come up with incorrect file system parameters, start of file system and clustersize being most important:

As directory entries point to start cluster, file allocation table refers to cluster, two factors that need to be 'guessed' correctly is offset from which we start counting clusters + sectors per cluster.

Tools > Reopen Volume Parameters allows you to modify these parameters but modifying these requires understanding of FAT32 file system internals (and a bit of luck?).

enter image description here

Assuming NTFS a similar story applies, this time however it's the MFT that is important: How much of MFT did survive?

MFT usually is towards the start of the volume, it however common the MFT is fragmented and those additional fragments have a better chance of surviving.

enter image description here

The more of the MFT survives, the better and more complete file system reconstruction will be. You can only find out by trying.

Joep van Steen
  • 4,730
  • 1
  • 17
  • 34