Recover data after running “dd if=/dev/zero …” for a few seconds
Friday morning working on installing OpenWrt pivot overlay on an USB pendrive. I need to format the USB and as I was doing it quite so many times I wasn’t paying too much attention. Don’t do that at home 😉
The USB was recognized as
/dev/sdb1 on my laptop but on the router it was on
/dev/sda1. As you have probably already guessed my main laptop hardrive was
I didn’t notice I wasn’t in the router console (f….. tabs) and after having successfully formatted the USB I decided to make it zero:
# dd if=/dev/zero of=/dev/sda1
I continue working on the laptop but when in typed ‘ls’ nothing is shown and even I got
unknown command. Uppps… something is going wrong. I just realized I was formatting my hard drive in stead of the USB.
Advice (take it if you want): In case this happens to you, press Ctrl+C as soon as you can to minimize the overwritten and lost data.
Most of my work for the last few years was there, programs, repositories, configurations, … I thought I was not going to be able to recover anything. Luckyly I pressed Ctrl+C quite quickly and only 1Gb was set to zero. Not everything was lost 😉
So if you ever come to that, don’t panic. You can at least recover what was not overwritten with 0, and even part of that I think it can also be recovered.
Next I’m explaining how I did it. It is quite short and easy procedure.
My system was installed under ext4. I think in ext2/3 the procedure should be working, but for fat, ntfs,… you should proceed differently.
I only got one partition for / with everything on it. Now I’ve learnt that’s not the best decision. It is better to format your drive with multiple partion for each type of data, at least with one partition for
/boot, another for
swap, another for
/ and another for
/home. This will help you on reinstallation and in cases like this one.
Get a copy of a system rescue disk or a distribution live CD. I installed it on my USB 😉
Make a binary image of your hard drive
Once you have the rescue disk, boot you system with it. Unfortunately you are not able to do it any other way.
Make a complete binary image of your disk on an external hard drive or through network. In order to work with the image, I don’t recommend you compress it as afterwards you will have to uncompress it, and that’s time.
# dd if=/dev/sda of=/path_to_external_drive/my_broken_disk.img # dd if=/dev/sda | ssh user@remotehost -d | 'dd of=/path_backup/my_broken_disk.img' # dd if=/dev/sda | gzip - | ssh user@remotehost dd of=/backup/drive.img.gz
It takes quite a long time depending on the size of your drive, so go for a long long walk.
The recovery method is based on the information on the superblocks that are stored in ext2/3/4 and that replicate filesytem information. It would be very difficult you zero all the hard drive and all the superblocks.
Using testdisk open your image. You can do it directly over your hard drive, but it is better not to work with it in order not to loose more information in case we do something wrong.
# testdisk my_broken_disk.img > [Proceed] > [Intel] > [Advanced] Partition Start End Size in sectors > 1 * Linux 0 32 33 14223 110 31 228497408 2 E extended 14223 142 62 14593 66 1 5939202 5 L Linux Swap 14223 143 1 14593 66 1 5939200
Select your data partition
Select [Supeblock] and copy them as this is the ones that are going to save you.
Partition Start End Size in sectors Linux 0 32 33 14223 110 31 228497408 superblock 0, blocksize=4096  superblock 32768, blocksize=4096  superblock 98304, blocksize=4096  superblock 163840, blocksize=4096  superblock 229376, blocksize=4096  superblock 294912, blocksize=4096  superblock 819200, blocksize=4096  superblock 884736, blocksize=4096  superblock 1605632, blocksize=4096  superblock 2654208, blocksize=4096  To repair the filesystem using alternate superblock, run fsck.ext4 -p -b superblock -B blocksize device
You can try to use testdisk to recover the files but I didn’t succeed.
Find data partition
As we have made the complete disk image you need to find out where your data partition starts in order to latter mount it.
# parted my_broken_disk.img parted my_broken_disk.img GNU Parted 2.3 Using my_broken_disk.img Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) unit Unit? [compact]? B (parted) print Model: (file) Disk my_broken_disk.img: 120034123776B Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1048576B 116991721471B 116990672896B primary ext4 boot 2 116992769024B 120033640447B 3040871424B extended 5 116992770048B 120033640447B 3040870400B logical linux-swap(v1) (parted) quit
The Start number indicates where you partition begins. You can also get this information from testdisk data, but you need to do some aritmetics. This way there’s no error.
There is more information on mounting partitions from full disk images here.
Mount partion and recover data
Mount your data partition.
# losetup -o 1048576 /dev/loop1 my_broken_disk.img
Try to recover filesystem information from superblocks. If fsck can find a valid superblock you have a good chance to be able to recover part of the files that lived on your volume. It might even be able to restore your fs to a living state, however what’s zeroed, it’s zeroed. No one can do anything about that, except for the enterprises specialized in info recovery as we said before.
It is advisable and quicker to refer to a known not zeroed superblock. Choose one superblock (I took the last one) from the information you got with testdisk.
# fsck.ext4 -p -b 11239424 -B 4096 /dev/loop1 Follow any indication # fsck.ext4 -b 11239424 -B 4096 /dev/loop1
It will point all the inodes with broken links, etc. You will see the names of some of your dirs. Just say yes to everything. When you are asked if you want to link to `lost+found` say yes as this directory will be taken as root dir for the broken inodes.
Work with the recover data
If everything went as expected the image filesystem is fixed and the recoverable information is accesible.
Mount the partion on the loop device to a directory
# mount -t ext4 -o ro /dev/loop1 /path_to_mount/
All the recovered data would probably be in
lost+found directory, at least it was in my case. This directory is only root accesible.
# su # cd /path_to_mount/lost+found # ls #1179649 #1461384 #1464249 #1573254 #1576115 #1723175 #2235518 #1179651 #1461525 #1464389 #1573330 #1576253 #1723189 #2235529 #131073 #1461600 #1464476 #1573468 #1576444 #1723193 #2235578 #1441961 #1461740 #1464483 #1573616 #1576529 #1723285 #2235583 ....
Those directories and files are the ones recovered. If you enter any of them you can find your files, but in the incorrect mounting point. The best thing is to use
find to locate some known files so this way you can retrieve which directory allocates your formely
# find /path_to_mount/lost+found -iname "<regex_for_known_files>"
Once you are done with it you should umount everything. You can also make a new image of your restored disk or partition.
# umount /dev/loop1 # dd if=/dev/loop1 of=/path_to_backup/my_restored_disk.img # losetup -d /dev/loop1
And that’s all. Thanks God you have part of your data back.
 DataRecovery – Community Ubuntu Documentation
 TestDisk – CGSecurity
 Manual disk partitioning guide for Ubuntu 11.04
 Mounting partitions from full disk images
 Recover Data Like a Forensics Expert Using an Ubuntu Live CD – How-To Geek
 hard drive – Is there a way to recover files from a storage device partially overwritten with dd? – Ask Ubuntu
 Mounting a hard disk image including partitions using Linux | andremiller.net