0

I messed up when trying to benchmark write speed on an sdcard with important files on it.

sync; sudo dd if=/dev/zero of=/dev/sdb1 bs=1M count=1024; sync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5386 s, 45.6 MB/s
^C

I realized that I was writing directly to /dev/sdb1 instead of writing to a file inside the mounted card, so in fear of overwriting data, I canceled right after the benchmark seemed to be over (it wasn't). Now it will mount automatically, but does not show anything (cannot click on it in the file explorer, and gparted only shows it as an unknown exfat card.

What can I do?

4
  • You could try a data recovery company, see if they can pick bits of surviving data out of the area you didn't overwrite. I'm assuming the reason you're asking us in the first place is because you didn't consider your data so important as to have a backup :/
    – Tetsujin
    Aug 2, 2018 at 16:06
  • You can try to open your sd card using a hexeditor capable of reading partitions and see if there is anything left except of zeros. How big is your card? If you have been fast enough, you only killed the start of the partition but most of the data is still there. In this case, you might want to try testdisk for recovery. Aug 2, 2018 at 16:07
  • The card was 64Gb, and about 90% full. my guess is hopefully only ~1Gb of actual data was overwritten (unfortunately, at the beginning of the partition instead of in free space) but that in the end most my data (most of it replaceable but some pictures I want to recover as well). I have made several backups, but about two weeks are only there. Trying free version of EaseUS Data Recovery shows a lot of stuff still there, but I'm not sure I'll be able to recover without paying. Still scanning Aug 2, 2018 at 16:28
  • @AlessandroJeanteur As I already recomended: Testdisk (cgsecurity.org/wiki/TestDisk), it is a free tool and should be the right choice for your case. Aug 2, 2018 at 16:32

1 Answer 1

1

There are plenty of recovery applications, personally I find that photorec and foremost work best. Photorec is part of the testdisk package, foremost can be installed from the foremost package.

a) Photorec

Simply run $ photorec /dev/sdb now to open up photorec's interactive interface.

Hit return ([Proceed]) to select the disk. In the next screen, you're asked to select a partition. If photorec finds the correct partitions, you can select the one you want to recover the files from here. If it doesn't detect the partitions properly, simply select No partition [Whole disk] and hit return again to perform the [Search]. Once selected the filesystem type in the next screen, you need to select a directory in which the recovered files should be saved. Confirm with C.

b) Foremost

While photorec works by trying to find "data blocks" of the drive and media within using file carving, foremost does it a bit differently. It's still using the file carving concept but it ignores the type of underlying filesystem and directly works by copying segments of the drive into your RAM, which is then being scanned for file header types. Foremost comes with a lot of built-in headers to recover most types of common files, if you want to add custom headers/footers to detect less common file types, foremost offers you this ability.

To run foremost using the default options on the image, run the following command:

$ foremost -i /dev/sdb -v

You can use /dev/sdb1 here if you want to recover files from only that partition.

That will save all recovered files into output (new directory that foremost will create). You can specify another output directory using the -o flag, and -a to ignore errors/save corrupted files.

Optional: Filter the recovered files

This is optional, but sometimes you are only interested in specific types of files, or even worse: Recovery tools give you a million of files out of which thousands appear to be, for example, a JPEG file, but in reality it's just a corrupted file and not a picture at all. To filter these out you can use this answer I gave to another question on SuperUser.


How can you prevent this in the future

I see people messing their data up with dd way too often. It's just too easy. My recommendation:

#!/bin/bash
read -r -p "Have you checked at least TWICE if the parameters are correct? [y/N] " response
response=${response,,}
if [[ "$response" =~ ^(yes|y)$ ]]; then
    dd "$@"
else
    echo "Better be safe than sorry."
fi

Save this as /usr/bin/sdd or whatever name you'd like. chmod +x it afterwards. From now on, always use sdd instead of dd.

1
  • I recommend using both tools on the entire disk, not just one partition. This won't bring back files that were overwritten by dd, those are gone. It should without issues bring back everything else though.
    – confetti
    Aug 2, 2018 at 16:36

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