lichti · November 20, 2015 16:42
diff --git a/recovery-dd.txt b/recovery-dd.txt
 https://devjlanza.wordpress.com/2012/05/11/recover-data-after-running-dd-ifdevzero-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 /dev/sda1.

 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.



 Preliminaries

 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 ;)

 There are plenty of utilities for recovering data. For my case I only used testdisk.

 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.

 Superblocks

 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 /home, etc.

 # 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.
	https://devjlanza.wordpress.com/2012/05/11/recover-data-after-running-dd-ifdevzero-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 /dev/sda1.

	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.



	Preliminaries

	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 ;)

	There are plenty of utilities for recovering data. For my case I only used testdisk.

	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.

	Superblocks

	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 /home, etc.

	# 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.