pendriveIn march 2013 my flash pendrive has gone crazy. This is an unwanted situation what can happen to everyone. I have backup, but old, from 2-3 months ago. Pendrive is dead in specified way. He shown their presence not in all time, for second-third mount.

I not remember all steps in this situation (6 months past) but i found some notes writed myself  of my recovery process, so i try to explain what i do to recover data from my usb stick.

Some info:
– my pendrive it’s an Sandisk Cruzer Contour 16 GB (with about 2GB of important data)
– he is detected by system (windows) and correctly mounted, but not everytime…
–  same situation in linux. Sometime is shown, sometime filesystem is not detected
– sometime pendrive are not mounted and was displayed as unknown device…
– files are listed in root directory, can be opened, read (due to recovery process i not tried to write anything on stick)
– directories are listed correctly, but not all of them – when i enter into specified directory (there are more than one of them), my pendrive are dissapear from system
– he is no more present in system until i plug off and insert again (linux + windows too, tested in few computers)
– same problem spotted in USB 3.0, 2.0 and 1.1 ports
– i have copy of entire flash stick from 2 months ago (too old! – i urgently need current data)
– in pendrive are thousand of txt files (now i have 7.800 files, 2000 directories in one of the main root branches) – i saving my problems spotted in work into it… And this number is only for work – there are more of them, include my personally files…

Strange… i never seen problems like this one… Because i can see files and i can copy them, time to catch as much as possible…
I created directory on harddisk and tried to copy everything what i can. When system look on specified folder, pendrive is dissapearing from windows system (tried on XP + Win7). To copy i used an Directory Opus (my favorite filemanager), because if problem like this one is spotted a request dialog box is displayed, i can re-plug pendrive and click “skip” to omnit this dir. After entire operation i check recovered data – i lost content of maaany directories.

What to do next? How to recover this data? I tried almost all popular recovery programs available on windows platform.
Without success… But why?
– most of them are dead (process are “hung”) – i must kill this task on task manager.
– i got one system crash
– in almost every attempt entire system are frozen, i must re-plug pendrive, otherwise it’s not responding
– only few programs end scanning process, without ANY files or directories to recover (empty result)

Time to use linux and try manual recover, but how to do it?
I thought that the best way will be to copy entire pendrive into file on filesystem, mount them and later work on this copy to recover data…

First i tried to “dd” (copy entire pendrive sectory by sector), but same problem are spotted in linux too… “dd” are specific command, he exit into shell when see first read error…


When i putpendrive into usb slot, i seen two cases:
– pendrive are not mounted (log from system messages)

Mar  9 14:26:45 localhost kernel: [74409.897092] usb 2-6: new high-speed USB device number 63 using ehci_hcd
Mar  9 14:26:45 localhost kernel: [74410.012040] usb 2-6: New USB device found, idVendor=0781, idProduct=540e
Mar  9 14:26:45 localhost kernel: [74410.012051] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar  9 14:26:45 localhost kernel: [74410.012059] usb 2-6: Product: Cruzer Contour
Mar  9 14:26:45 localhost kernel: [74410.012065] usb 2-6: Manufacturer: SanDisk Corporation
Mar  9 14:26:45 localhost kernel: [74410.012072] usb 2-6: SerialNumber: 01655111A742CE23
Mar  9 14:26:45 localhost kernel: [74410.016182] scsi56 : usb-storage 2-6:1.0
Mar  9 14:26:45 localhost mtp-probe: checking bus 2, device 63: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6"
Mar  9 14:26:45 localhost mtp-probe: bus: 2, device: 63 was not an MTP device
Mar  9 14:26:46 localhost kernel: [74411.019467] scsi 56:0:0:0: Direct-Access     SanDisk  Cruzer Contour   4.08 PQ: 0 ANSI: 2
Mar  9 14:26:46 localhost kernel: [74411.019947] scsi 56:0:0:1: Direct-Access     SanDisk  Cruzer Contour   4.08 PQ: 0 ANSI: 2
Mar  9 14:26:46 localhost kernel: [74411.024191] sd 56:0:0:0: Attached scsi generic sg2 type 0
Mar  9 14:26:46 localhost kernel: [74411.024507] sd 56:0:0:1: Attached scsi generic sg3 type 0
Mar  9 14:26:46 localhost kernel: [74411.024783] sd 56:0:0:0: [sdb] 131071 512-byte logical blocks: (67.1 MB/63.9 MiB)
Mar  9 14:26:46 localhost kernel: [74411.026172] sd 56:0:0:0: [sdb] Write Protect is off
Mar  9 14:26:46 localhost kernel: [74411.026654] sd 56:0:0:0: [sdb] No Caching mode page present
Mar  9 14:26:46 localhost kernel: [74411.026658] sd 56:0:0:0: [sdb] Assuming drive cache: write through
Mar  9 14:26:46 localhost kernel: [74411.027047] sd 56:0:0:1: [sdc] 131071 512-byte logical blocks: (67.1 MB/63.9 MiB)
Mar  9 14:26:46 localhost kernel: [74411.027785] sd 56:0:0:1: [sdc] Write Protect is off
Mar  9 14:26:46 localhost kernel: [74411.028927] sd 56:0:0:1: [sdc] No Caching mode page present
Mar  9 14:26:46 localhost kernel: [74411.028933] sd 56:0:0:1: [sdc] Assuming drive cache: write through
Mar  9 14:26:46 localhost kernel: [74411.032041] sd 56:0:0:0: [sdb] No Caching mode page present
Mar  9 14:26:46 localhost kernel: [74411.032046] sd 56:0:0:0: [sdb] Assuming drive cache: write through
Mar  9 14:26:46 localhost kernel: [74411.033544] sd 56:0:0:1: [sdc] No Caching mode page present
Mar  9 14:26:46 localhost kernel: [74411.033547] sd 56:0:0:1: [sdc] Assuming drive cache: write through
Mar  9 14:26:46 localhost kernel: [74411.049173]  sdb: unknown partition table
Mar  9 14:26:46 localhost kernel: [74411.049673]  sdc: unknown partition table
Mar  9 14:26:46 localhost kernel: [74411.055534] sd 56:0:0:1: [sdc] No Caching mode page present
Mar  9 14:26:46 localhost kernel: [74411.055539] sd 56:0:0:1: [sdc] Assuming drive cache: write through
Mar  9 14:26:46 localhost kernel: [74411.055542] sd 56:0:0:1: [sdc] Attached SCSI removable disk
Mar  9 14:26:46 localhost kernel: [74411.056033] sd 56:0:0:0: [sdb] No Caching mode page present
Mar  9 14:26:46 localhost kernel: [74411.056037] sd 56:0:0:0: [sdb] Assuming drive cache: write through
Mar  9 14:26:46 localhost kernel: [74411.056040] sd 56:0:0:0: [sdb] Attached SCSI removable disk

 

Otherwise i see this log in kernel messages – but he are mounted sucessfully, in system log (/var/log/messages) we can see:

Mar  9 14:27:31 localhost kernel: [74456.279351] usb 2-6: USB disconnect, device number 63

Mar  9 14:28:11 localhost kernel: [74495.867079] usb 2-6: new high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:11 localhost kernel: [74495.982233] usb 2-6: New USB device found, idVendor=0781, idProduct=540e
Mar  9 14:28:11 localhost kernel: [74495.982244] usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar  9 14:28:11 localhost kernel: [74495.982252] usb 2-6: Product: Cruzer Contour
Mar  9 14:28:11 localhost kernel: [74495.982258] usb 2-6: Manufacturer: SanDisk Corporation
Mar  9 14:28:11 localhost kernel: [74495.982265] usb 2-6: SerialNumber: 0000184A88701037
Mar  9 14:28:11 localhost kernel: [74495.983154] scsi57 : usb-storage 2-6:1.0
Mar  9 14:28:11 localhost mtp-probe: checking bus 2, device 64: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6"
Mar  9 14:28:11 localhost mtp-probe: bus: 2, device: 64 was not an MTP device
Mar  9 14:28:12 localhost kernel: [74496.986309] scsi 57:0:0:0: Direct-Access     SanDisk  Cruzer Contour   4.08 PQ: 0 ANSI: 2
Mar  9 14:28:12 localhost kernel: [74496.986916] scsi 57:0:0:1: CD-ROM            SanDisk  Cruzer Contour   4.08 PQ: 0 ANSI: 2
Mar  9 14:28:12 localhost kernel: [74496.988970] sd 57:0:0:0: Attached scsi generic sg2 type 0
Mar  9 14:28:12 localhost kernel: [74496.993978] sd 57:0:0:0: [sdb] 32063117 512-byte logical blocks: (16.4 GB/15.2 GiB)
Mar  9 14:28:12 localhost kernel: [74496.995499] sd 57:0:0:0: [sdb] Write Protect is off
Mar  9 14:28:12 localhost kernel: [74496.995988] sr1: scsi3-mmc drive: 8x/40x writer xa/form2 cdda tray
Mar  9 14:28:12 localhost kernel: [74496.996339] sr 57:0:0:1: Attached scsi generic sg3 type 5
Mar  9 14:28:12 localhost kernel: [74496.996464] sd 57:0:0:0: [sdb] No Caching mode page present
Mar  9 14:28:12 localhost kernel: [74496.996468] sd 57:0:0:0: [sdb] Assuming drive cache: write through
Mar  9 14:28:12 localhost kernel: [74496.999711] sd 57:0:0:0: [sdb] No Caching mode page present
Mar  9 14:28:12 localhost kernel: [74496.999716] sd 57:0:0:0: [sdb] Assuming drive cache: write through
Mar  9 14:28:12 localhost kernel: [74497.001731]  sdb: sdb1
Mar  9 14:28:12 localhost kernel: [74497.007120] sd 57:0:0:0: [sdb] No Caching mode page present
Mar  9 14:28:12 localhost kernel: [74497.007125] sd 57:0:0:0: [sdb] Assuming drive cache: write through
Mar  9 14:28:12 localhost kernel: [74497.007129] sd 57:0:0:0: [sdb] Attached SCSI removable disk
Mar  9 14:28:14 localhost kernel: [74498.799766] sd 57:0:0:0: [sdb] Unhandled sense code
Mar  9 14:28:14 localhost kernel: [74498.799774] sd 57:0:0:0: [sdb]  
Mar  9 14:28:14 localhost kernel: [74498.799778] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar  9 14:28:14 localhost kernel: [74498.799782] sd 57:0:0:0: [sdb]  
Mar  9 14:28:14 localhost kernel: [74498.799785] Sense Key : Medium Error [current] 
Mar  9 14:28:14 localhost kernel: [74498.799791] sd 57:0:0:0: [sdb]  
Mar  9 14:28:14 localhost kernel: [74498.799795] Add. Sense: Unrecovered read error
Mar  9 14:28:14 localhost kernel: [74498.799799] sd 57:0:0:0: [sdb] CDB: 
Mar  9 14:28:14 localhost kernel: [74498.799801] Read(10): 28 00 01 90 95 c0 00 00 01 00
Mar  9 14:28:14 localhost kernel: [74498.799816] blk_update_request: 59 callbacks suppressed
Mar  9 14:28:14 localhost kernel: [74498.799819] end_request: critical target error, dev sdb, sector 26252736
Mar  9 14:28:14 localhost kernel: [74498.802117] sd 57:0:0:0: [sdb] Unhandled sense code
Mar  9 14:28:14 localhost kernel: [74498.802120] sd 57:0:0:0: [sdb]  
Mar  9 14:28:14 localhost kernel: [74498.802122] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar  9 14:28:14 localhost kernel: [74498.802124] sd 57:0:0:0: [sdb]  
Mar  9 14:28:14 localhost kernel: [74498.802126] Sense Key : Medium Error [current] 
Mar  9 14:28:14 localhost kernel: [74498.802129] sd 57:0:0:0: [sdb]  
Mar  9 14:28:14 localhost kernel: [74498.802131] Add. Sense: Unrecovered read error
Mar  9 14:28:14 localhost kernel: [74498.802133] sd 57:0:0:0: [sdb] CDB: 
Mar  9 14:28:14 localhost kernel: [74498.802134] Read(10): 28 00 01 90 95 c1 00 00 01 00
Mar  9 14:28:14 localhost kernel: [74498.802142] end_request: critical target error, dev sdb, sector 26252737
Mar  9 14:28:14 localhost kernel: [74498.907094] usb 2-6: reset high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:14 localhost kernel: [74499.022179] sd 57:0:0:0: [sdb] Unhandled error code
Mar  9 14:28:14 localhost kernel: [74499.022187] sd 57:0:0:0: [sdb]  
Mar  9 14:28:14 localhost kernel: [74499.022191] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Mar  9 14:28:14 localhost kernel: [74499.022195] sd 57:0:0:0: [sdb] CDB: 
Mar  9 14:28:14 localhost kernel: [74499.022198] Read(10): 28 00 01 90 95 c2 00 00 7e 00
Mar  9 14:28:14 localhost kernel: [74499.022213] end_request: I/O error, dev sdb, sector 26252738
Mar  9 14:28:14 localhost kernel: [74499.126057] usb 2-6: reset high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:15 localhost kernel: [74499.352068] usb 2-6: reset high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:15 localhost kernel: [74499.576076] usb 2-6: reset high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:15 localhost kernel: [74499.801069] usb 2-6: reset high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:15 localhost kernel: [74500.026060] usb 2-6: reset high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:15 localhost kernel: [74500.250073] usb 2-6: reset high-speed USB device number 64 using ehci_hcd
Mar  9 14:28:16 localhost kernel: [74500.365068] sd 57:0:0:0: [sdb] Unhandled error code
Mar  9 14:28:16 localhost kernel: [74500.365074] sd 57:0:0:0: [sdb]  
Mar  9 14:28:16 localhost kernel: [74500.365076] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Mar  9 14:28:16 localhost kernel: [74500.365078] sd 57:0:0:0: [sdb] CDB: 
Mar  9 14:28:16 localhost kernel: [74500.365080] Read(10): 28 00 01 90 95 c3 00 00 7d 00
Mar  9 14:28:16 localhost kernel: [74500.365090] end_request: I/O error, dev sdb, sector 26252739
Mar  9 14:28:16 localhost kernel: [74500.367664] sd 57:0:0:0: [sdb] Unhandled sense code
Mar  9 14:28:16 localhost kernel: [74500.367667] sd 57:0:0:0: [sdb]  
Mar  9 14:28:16 localhost kernel: [74500.367668] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
(...) <--- entries deleted, few lines repeated frequently
Mar  9 14:28:16 localhost kernel: [74500.518425] sd 57:0:0:0: [sdb]  
Mar  9 14:28:16 localhost kernel: [74500.518428] Sense Key : Medium Error [current] 
Mar  9 14:28:16 localhost kernel: [74500.518433] sd 57:0:0:0: [sdb]  
Mar  9 14:28:16 localhost kernel: [74500.518436] Add. Sense: Unrecovered read error
Mar  9 14:28:16 localhost kernel: [74500.518441] sd 57:0:0:0: [sdb] CDB: 
Mar  9 14:28:16 localhost kernel: [74500.518443] Read(10): 28 00 01 90 95 ff 00 00 01 00

 

Ok, let’s try to recover.
– i tried to “dd” entire pendrive – they are spotted first read error about 4 GB of data and finished work. So we have hardware error, this is not a corruption of filesystem. Badly 🙁 This complicated entire situation…
– next idea – use and “ddrescure”. This program can copy and retry read of damaged sectors, or skip some sectors when read error are spotted.

 

First usage, with “-p” parameter to allocate file equal to size of entire device (16 GB in my case). In linux file are created in one second (size are allocated). File are created, filled with zeros.

ddrescue --no-split --block-size=512 --cluster-size=2048 --synchronous --timeout=2 --verbose -v --retrim -p /dev/sdb pen logfile

 

And next, i created script to avoid mistake when i will work with recovery process…

root@localhost pen2# cat skrypt.sh 
ddrescue --no-split --block-size=512 --cluster-size=2048 --synchronous --timeout=2 --verbose -v --retrim --skip-size=1024KiB /dev/sdb pen logfile

root@localhost pen2# ll
razem 16031565
-rwxrwxrwx 1 root root         829 03-09 11:21 logfile
-rwxrwxrwx 1 root root 16416315904 03-09 11:47 pen
-rwxrwxrwx 1 root root         146 03-08 22:47 skrypt.sh

Recovery process  looks like that:

root@localhost pen2# ./skrypt.sh 

GNU ddrescue 1.16
About to copy 16416 MBytes from /dev/sdb to pen
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 2048 sectors       Initial skip size: 2048 sectors
Sector size: 512 Bytes
Max retries: 0    
Max time since last successful read: 2 s
Direct: no    Sparse: no    Split: no    Truncate: no    

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:    16407 MB,  errsize:    1536 B,  errors:       2
current position:      4314 MB,     current sector: 8427522
last block size:     932141 kB

Current status
rescued:    16407 MB,  errsize:    1536 B,  current rate:        0 B/s
   ipos:     4314 MB,   errors:       2,    average rate:        0 B/s
   opos:     4314 MB,     time since last successful read:       0 s
Copying non-tried blocks...

 

 

When recovery are started, we can see an “current rate” (current speed of data copy) are changed frequently with different values. But in this time pendrive are dead sometime and this value are equal to zero (in this case), or have value of previous state (he is not changed anymore) – it’s freezed. We can easily see when this problem occurs in system log (/var/log/messages). This mean, that i must remove pendrive from usb port (ddrescue process are exiting when this is done, to shell), insert it again, check messages (if he mounted correctly!) and start my script again… And this until entire surface has been read. Lower are example of messages when error read is spotted:

Mar  9 14:38:12 localhost kernel: [75096.748594] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.748602] Sense Key : No Sense [current] 
Mar  9 14:38:12 localhost kernel: [75096.748609] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.748616] <> ASC=0xff ASCQ=0xffASC=0xff <> ASCQ=0xff
Mar  9 14:38:12 localhost kernel: [75096.791591] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.791596] Sense Key : No Sense [current] 
Mar  9 14:38:12 localhost kernel: [75096.791603] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.791609] <> ASC=0xff ASCQ=0xffASC=0xff <> ASCQ=0xff
Mar  9 14:38:12 localhost kernel: [75096.834597] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.834603] Sense Key : No Sense [current] 
Mar  9 14:38:12 localhost kernel: [75096.834610] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.834617] <> ASC=0xff ASCQ=0xffASC=0xff <> ASCQ=0xff
Mar  9 14:38:12 localhost kernel: [75096.877600] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.877607] Sense Key : No Sense [current] 
Mar  9 14:38:12 localhost kernel: [75096.877614] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.877620] <> ASC=0xff ASCQ=0xffASC=0xff <> ASCQ=0xff
Mar  9 14:38:12 localhost kernel: [75096.920838] sd 57:0:0:0: [sdb]  
Mar  9 14:38:12 localhost kernel: [75096.920846] Sense Key : No Sense [current] 

 

Everytime we see new entries in logfile (where recovery process store information about progress), we remove pendrive and ddrecovery will skip part of unredable data…
Example of this file:

root@localhost pen2# cat logfile
 # Rescue Logfile. Created by GNU ddrescue version 1.16
 # Command line: ddrescue --no-split --block-size=512 --cluster-size=2048 --synchronous --timeout=2 --verbose -v --retrim --skip-size=1024KiB /dev/sdb pen logfile
 # current_pos current_status
 0x101400000 ?
 # pos size status
 0x00000000 0x042B4000 +
 0x042B4000 0x0000C000 ?
 0x042C0000 0xFCFD8000 +
 0x101298000 0x00038000 ?
 0x1012D0000 0x00000200 *
 0x1012D0200 0x0002FE00 ?
 0x101300000 0x00100000 *
 0x101400000 0x00298000 ?
 0x101698000 0x008A8000 +
 0x101F40000 0x000B8000 ?
 0x101FF8000 0x0002C000 +
 0x102024000 0x00004000 ?
 0x102028000 0x2926F000 +
 0x12B297000 0x00401000 ?
 0x12B698000 0x1F5C20000 +
 0x3212B8000 0x00008000 ?
 0x3212C0000 0x79BEA000 +
 0x39AEAA000 0x00002000 ?
 0x39AEAC000 0x0002E000 +
 0x39AEDA000 0x00002000 ?
 0x39AEDC000 0x378F5A00 +

 

 

How much sectors are processed?

# current_pos current_status
0x101400000 ?

 

 

When entire pendrive are copied, we can try to re-read skipped blocks (when error are spotted, ddrecovery will notice this one and next time try to start with error_position+skip_sectors_number.
Because half year past from my rescue problems, i not remind what exactly i do to decrease amount of unread data.
I recovered almost all surface of my pendrive, without about 10 MB unreadable sectors.
I tried also with –direct option, read with raw devices, but same problem occurs (but this may help sometime, with real harddrives).
I think i can decrease them, but… I spend almost 2-3 night at this problem, come to bed at 04:00 (and awake to work at 07:00).
Finally in sunday (in saturday exactly, because is 04:00 of saturday), i decided to come to sleep and try to recover of this unreadable data later, when i get some rest. But when i awake new problem is come: when i put pendrive into usb slot, he are completly dead – not detected by kernel…


 

 

DDresue have a possibility to start (with “-i number”) on specified sector, so if you have error on position 0x042B4000 we can try to start read few sectors later, like “-i 69943299” = in this example at +3 sectors that error spotted.

root@localhost pen2# echo $((0x042B4000))
69943296

When first pass of recovery is done, You can read damaged section slowly trying to recover as much data as possible. Let’s think what we can do?

EXAMPLE:

  • We have skip size of 10 units . If error occurs, program will skip +10 sectors forward.
  • Next time, we can try to start with this damaged sector again
  • if fails, we can try start few sectors later
  • if fails too, try to start read reverse (-R or –reverse) parameter from start+10 position. Program will “read backward” data, 10, 9,8,7… And we can fast shrink unrecovered area to error position.
  • due to this, when You attempting to recover your data, don’t think too much about greater “skip-size”. You can still back to read this data later.
  • also decrease retry count – this will decrease time to recover data

How to read and understand logfile created by this program? I’m not remember this too good, so treat this part of tutorial as not trusted at all…
0x042B4000 0x0000C000 ?
sector_number amount_of_data error_type

sector_number is simple ==> this is position when error is spotted.
amount_of_data ==> amount of unredable data
0x0000C000 ==> 49152 unread sectors
next jump when we try to read, is ==> 0x042B4000 + 0x0000C000 = 0x042C0000

Initial status (read from logfile)
rescued:    16407 MB,  errsize:   1049 kB,  errors:       2
current position:      4315 MB,     current sector: 8429568
last block size:     932141 kB

Current status
rescued:    16407 MB,  errsize:   1049 kB,  current rate:        0 B/s
   ipos:     4315 MB,   errors:       2,    average rate:        0 B/s
   opos:     4315 MB,     time since last successful read:       9 s
Copying non-tried blocks...

# current_pos current_status
0x101400000 ?

# pos size status

0x00000000 0x042B4000 +
0x042B4000 0x0000C000 ?
0x042C0000 0xFCFD8000 +
0x101298000 0x00038000 ?
0x1012D0000 0x00000200 *
0x1012D0200 0x0002FE00 ?

 

Every line in the list of data blocks describes a block of data. It contains 2 non-negative integers and a status character. The first integer is the starting position of the block in the input file, the second integer is the size (in bytes) of the block. The status character is one of these:
Character Meaning
‘?’ copying non-tried blocks
‘*’ trimming non-trimmed blocks
‘/’ splitting non-split blocks
‘-‘ retrying bad sectors
‘F’ filling specified blocks
‘G’ generating approximate logfile
‘+’ finished

Need some help with understanding this? There are small tool what can help You with analyse:

ddrescueview_01ddrescueview_02ddrescueview_03

http://sourceforge.net/projects/ddrescueview
Viewer for ddrescue logfiles (saved as filename.txt). Graphic interpretation of recovery process and sector allocation. I found this program in last few days…


 

Recovery process is done for me now… – source drive (pendrive) are dead, no more possibility to increase amount of unread sectors…
We now mount created image of pendrive

First, we need to locate parition on pendrive:

fdisk -l ./recovered_image_file

Dysk ./recovered_image_file: 1573 MB, bajtów: 1573863424
głowic: 255, sektorów/ścieżkę: 63, cylindrów: 191, w sumie sektorów: 3073952
Jednostka = sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Identyfikator dysku: 0x4157a15c

Urządzenie Rozruch   Początek      Koniec   Bloków   ID  System
./pen1   *          52    31294619    15647284    c  W95 FAT32 (LBA)

 

And we now known, that FAT32 partition start at 52 sector.
Start_sector * sector_size = start_position_in_bytes
52 * 512 = 26624

 

So let’s mount this file into our filesystem:

mkdir /media/test
mount -o loop,ro,offset=26624,iocharset=utf8 /media/win_c/pen2/recovered_image_file /media/test

 

Finally i mount recovered image file and (what was amazing), directory tree are readable without any problems, i can enter into all directories where previously i can’t enter. So i can copy all files.

This look as happy-end, but “life are hard and full of ambushes”.
I can’t read some sectors, do you remember? I seen this problem later, when i tried to catch this damaged files…
Some of them are filled with zeroes (non-readed sectors are still filled with zero byte value), mostly with 512 bytes (= equal to unreaded blocksize) size.

 

How to catch (find) those damaged one?

  • Because i have very simple situation (i have old backup from 2-3 months) my recovery process are simple:
  • get all files from old backup
  • copy over them all newly recovered files
  • find damaged files
  • if filesize are equal to old one, copy old file again (overwrite, because content are same (in mostly situations)) – You can find differencies first to be sure. Check modification date first.
  • if filesize are different that old file, this is a problem, need manual check – some part of file is still undamaged – i keep data in .txt format, so is easily recoverable…

 

Sounds simple. But how to catch those damaged files?

find . -exec grep -cHaP $(for i in {1..150}; do echo -n \\x00; done) {} \; | grep ":1"

In this example, we check all files in current directory (inside all other current dir too) – we searching for a files that contains pack of 150 bytes of zero’s. Only those will be listed.  Txt files not contains zeros so this is simple. But other files can… and this is terrible – .doc, .xls, pictures… New word/excel format are gziped inside, i think program will tell you that file is damaged when we try to open it, but old format and pictures… need check them manually (best way is differ old (if you have copy of course) with recovered – now you have answer why i overwrited all files with old backup – but this is my situation… You must think what to do in Your case. If file are never modified after last backup, overwrite it. Date of modification is changed… ups need manual check.

 

You can omit some filetypes, with (can be used as exclude pattern in find but maybe im too lazy…):

find . -exec grep -cHaP $(for i in {1..10}; do echo -n \\x00; done) {} \; | grep ":1" | grep -viE ".doc|.xls|.jpg|.png"

 

And this is the end. One advice: Remind to make frequent backup….