I accidentally wrote a 512 bytes binary to the wrong USB disk with dd and the device doesn't show any partitions with fdisk anymore.

I thought all the data was gone, but dd if=/dev/sdx | strings shows that the data seems to be still there, since dd fortunately limited itself to the first 512 bytes. Is there any way to recover it?

The disk had two partitions: an ext4 (~4GB) one and the remaining of 16GB were formatted as NTFS.


2 Answers 2


It depends on what exactly was there before, but it might be easy(-ish) to recover from this.

  1. Use dd to create a full image of your USB drive on a safe location.

  2. Use dd to create a full image of your USB drive on a safe location.

  3. Yes, please do keep a full image. Data recovery operations can often cause more damage than one would expect.

  4. Try to remember what the partition layout on that USB drive was like. Write it down. It might help if you have system logs from when that disk (before being messed-up) is detected by the Linux kernel - quite often it will print-out some data about the detected partitions.

  5. Use fdisk to recreate the MBR with the same partition table. Do not format and/or fsck any partitions.

  6. Try to mount your partitions with the read-only (-o ro) mount option.

  7. If it succeeds, try to copy all files over to a safe location and watch your terminal and logs for I/O errors - the typical way for partition boundary errors to be expressed is via out-of-bound accesses on the underlying device.

  8. If the copy fails, restore the image and go back to step 4.

  9. Did I mention having a full image of the USB drive before doing anything else?

PS: You might also want to have a look at tools like TestDisk, that attempt to automate the recovery process. But you should still get an full image first.

PS2: If you feel comfortable enough, you could also experiment a bit. If you can make a reasonable assumption for the starting point of the first partition, then you can use tune2fs -l to get the exact size of the first partition, which would allow you to hunt for the start of the second one.

  • #1: dd if=/dev/sdx of=backup.img right?
    – edmz
    Commented Oct 31, 2015 at 15:56
  • @black: Yes. You might want to put a bs=... option to increase the block size and speed it up a bit.
    – thkala
    Commented Oct 31, 2015 at 15:59
  • A good blocksize to use is bs=64K. TestDisk is definitely worth trying, and it can work on disk image files as well as on actual disks. Good luck!
    – PM 2Ring
    Commented Oct 31, 2015 at 16:41
  • Running cat /dev/sdx >backup.img would be faster than dd in many circumstances and certainly no slower in this one. Commented Nov 1, 2015 at 21:52

To restore the ext4 partition and its data, I thought about creating one, disk-wide ext4 partition. This allowed me to get access to the data and retrieve information about the partition with tune2fs -l, as suggested by @thkala. This information looks very feasible and, so, unaltered.

Very interestingly, gparted is somewhat able to figure out the actual partition size as turns out from this warning it shows:

10.96 GiB of unallocated space within the partition. To grow the file system to fill the partition, select the partition and choose the menu item:

because 11GiB was roughly the dimension of the NTFS partition.

enter image description here

Notice the unused space that, IIRC, it was the space the ext4 had still free. The unallocated space gparted recognizes seems to be NTFS partition; now, how can I restore that one too, maybe by finding out where the first partition ends i.e. its total byte count?

Finally TestDisk handled that effortlessly.

  • Excellent. Please would you accept your own answer so it's clear you had an acceptable solution to your question. Commented Nov 1, 2015 at 21:53
  • @roaina Yes I shall when the two day minimum opening duration expires.
    – edmz
    Commented Nov 2, 2015 at 9:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .