Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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.
It depends on what exactly was there before, but it might be easy(-ish) to recover from this.
Use dd to create a full image of your USB drive on a safe location.
Use dd to create a full image of your USB drive on a safe location.
Yes, please do keep a full image. Data recovery operations can often cause more damage than one would expect.
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.
Use fdisk to recreate the MBR with the same partition table. Do not format and/or fsck any partitions.
Try to mount your partitions with the read-only (-o ro) mount option.
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.
If the copy fails, restore the image and go back to step 4.
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.
bs=... option to increase the block size and speed it up a bit.
bs=64K. TestDisk is definitely worth trying, and it can work on disk image files as well as on actual disks. Good luck!
cat /dev/sdx >backup.img would be faster than dd in many circumstances and certainly no slower in this one.
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.
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.