Arch Linux

terroirman

Member

Registered: 2014-10-05

Posts: 2

Problem rescuing DDrescue multiple images

Hi,

I recently observed one of my drive was generating problems and found read errors via smartctl. I quickly started to search how to recover it. And started reading on GNU DDrescue. Since only 300gb of data was used over the 1tb, I thought I could restore it on my existing drives and go buy a new one the next day.

Following the guidelines at https://help.ubuntu.com/communityDataRe … m_or_drive, I started to recover as much data as possible

ddrescue --no-split --sparse /dev/sdd1 imagefile logfile

Thinking the --sparse option should save me the space I needed to recover only non-zero data.

However, things didn't go that way. I got an error telling me there was no more space on the drive. So I thought, I misunderstood the --sparse option. Following this the same guideline a little further ( Ran out of space...) I continued the recovery with the same logfile with different output files until a full 1tb was created.

I needed 4 files through 4 filesystem to get it through.

Here are my questions :
- Why are the files created an incremental of the previous one ? I.e.: 391G, 482G, 504G and finally 931G.

- Also, brinding them together with

sudo losetup /dev/loop1 /media/Drive1/image
sudo losetup /dev/loop2 /media/Drive2/image
sudo mdadm -B /dev/md0 -l linear -n 2 /dev/loop1 /dev/loop2

mdadm --detail /dev/md0
/dev/md0:
        Version : 
  Creation Time : Sat Oct  4 19:31:14 2014
     Raid Level : linear
     Array Size : 2418016576 (2306.00 GiB 2476.05 GB)
   Raid Devices : 4
  Total Devices : 4

          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

       Rounding : 64K

    Number   Major   Minor   RaidDevice State
       0       7        1        0      active sync   /dev/loop1
       1       7        2        1      active sync   /dev/loop2
       2       7        3        2      active sync   /dev/loop3
       3       7        4        3      active sync   /dev/loop4

obviouly leads to a 2.4tb file. Is is usable ?

- Is it even possible to continue the recovering with this set of files, if so how ?

- What would be your recommandation in my situation.

Don't hesitate to let me know if/where I made an error.

Thanks a lot for your help.

terroirman

Member

Registered: 2014-10-05

Posts: 2

Re: Problem rescuing DDrescue multiple images

Hi again, I found a solution to my problem. While creating a loopback with the different files, an offset and sizelimit can be specified.

Ie.:

losetup -f --show --sizelimit 456 --offset=123 ./rescue/rescue.file

But first, I had to determine where to start and stop in each file. Finding the starting point because ddrescue padded the begginning with zeros. And finding the ending point because, when ddrescue is stopped, the log file isn't updated (it could have only been updated a moment ago) and doesn't show the lasts sectors scanned. So a small part of ddrescue work has been redone each time I restarted the scan.

With DD and xxd, I looked in the second file, starting at the size of the first file (in sector, filessize/512) and going backward until I found such pattern (ie, all zeros, and then data). I went backward a couple more time to ensure the zeros weren't just unused space. :

dd if=./temp/rescue.file count=2 skip=819230719 | xxd

00001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000200: 605e 4978 3c90 3e1d c6a4 adcb 238b 045d  `^Ix<.>.....#..]
0000210: a7f4 10a2 2146 326c 6458 c946 2162 eeac  ....!F2ldX.F!b..
0000220: b8f9 5a8e 7420 6128 96f4 b859 dd94 3d2f  ..Z.t a(...Y..=/
0000230: 3361 d294 3c09 2d21 c526 2123 0643 8422  3a..<.-!.&!#.C."

Basically, 819230719 is the last sector of the first file I want to use. Some more data exist further in that file, but as stated above, it overlaps with the beginning of the second file. 819230720 is the starting sector of the second one (because before that, its all zeros). Since losetup offset/size parameters are in bytes, 819230720 needs to be used :

Then, I could create the loopbacks with just the portion of the files I needed :

losetup -f --show --sizelimit 419446128640 ./rescue/rescue.file          #419446128640=819230720*512
losetup -f --show --offset 419446128640 --sizelimit 97668694016 ./temp/rescue.file          #97668694016=190759168*512

The second number (97668694016) has been determined with the same method with the second and third file. I did the same for each file.

Now that I had 4 loopbacks, I realized mdadm wasn't the right way to go to bring them together. The reason is that it rounds to 64k and cause the total size of the array to be smaller than the sums of the loopbacks.

dmsetup is the right tool to bring them together :
1- A table file needs to be built to feed dmsetup. Mine looked like this :

0 819230720 linear /dev/loop0 0
819230720 190759168 linear /dev/loop1 0
1009989888 45385984 linear /dev/loop2 0
1055375872 896060846 linear /dev/loop3 0

2- Then, creating the array :

dmsetup create dm0 ./table

Which can be found under /dev/mapper/dm0 in my case.

From there:
- I did a fsck on the new array.
- I mounted the array
- I copied the data in my new drive
- With ddrutility (ddru_findbad), I could find which files would correspond to badblocks identified by ddrescue.

Hopes that'll help someone in a similar situation!

PS.:
I still don't understand the root cause of all of this. Ie.: Why ddrescue padded the beggining of all new files with zeros ? If anyone know, please let me know !

Last edited by terroirman (2014-10-15 00:41:15)