LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   ddrescue help (https://www.linuxquestions.org/questions/linux-software-2/ddrescue-help-4175494328/)

jhilgeman 02-09-2014 09:14 AM

ddrescue help
 
I'm trying to use ddrescue to help a family member whose 750gb laptop HDD is failing (Windows 7). They went and bought a 1tb laptop drive and so I loaded up the SystemRescue CD on their laptop and popped the new one into a USB enclosure, used fdisk to set up matching partitions (for the 3 partitions that matter) and began to try and run ddrescue on the main data partition:

Code:

ddrescue -f -v -r 3 /dev/sda2 /dev/sdb2 /tmp/ddrescue.log
1. For the first 50 gb or so, it seemed like 95% of it was "rescued" while the errsize was maybe 5 gb. I left it and came back about an hour or two later and it was now at 150 gb, but now the errsize was about 146 gb and the rescued was only 4 gb. My first question is - why would suddenly all of that "rescued" amount go away and become errors?

2. After pass 1 (copying), it's now trimming failed data. Pass 1 ended with roughly the same ratio with only about 25 gb rescued out of the 700 gb on the partition. It's "trimmed" about 500 gb so far and the rescued amount has only increased to about 45 gb.

3. I noticed the old drive has a 4k physical sector size and 512 byte logical sector size - would not specifying a 4k sector size have anything to do with the problems? Here's fdisk -l output for the drives:

Code:

root@sysresccd /root % fdisk -l

Disk /dev/sda: 750.2 GB, 750156374016 bytes, 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xb7b7c155

  Device Boot      Start        End      Blocks  Id  System
/dev/sda1  *        2048      409599      203776    7  HPFS/NTFS/exFAT
/dev/sda2          409600  1425383423  712486912    7  HPFS/NTFS/exFAT
/dev/sda3      1425383424  1456826367    15721472    7  HPFS/NTFS/exFAT
/dev/sda4      1456826368  1465147119    4160376    c  W95 FAT32 (LBA)

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000952ec

  Device Boot      Start        End      Blocks  Id  System
/dev/sdb1            2048      409599      203776    7  HPFS/NTFS/exFAT
/dev/sdb2          409600  1425383423  712486912    7  HPFS/NTFS/exFAT
/dev/sdb3      1425383424  1456826367    15721472    7  HPFS/NTFS/exFAT

Here's the current output:
Code:

root@sysresccd /root % ddrescue -f -v -r 3 /dev/sda2 /dev/sdb2 /tmp/ddrescue.log


GNU ddrescue 1.16
About to copy 729586 MBytes from /dev/sda2 to /dev/sdb2
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors      Initial skip size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
rescued:    44881 MB,  errsize:    684 GB,  current rate:    94208 B/s
  ipos:  201835 MB,  errors:    1387,    average rate:    797 kB/s
  opos:  201835 MB,    time since last successful read:      0 s
Trimming failed blocks...

Any help would be appreciated. Also, my understanding is that since I'm using a logfile, I can interrupt and re-run the same command to resume where I left off. Is that correct? And if I do that, but change the sector size, will it cause problems since it's already beyond the first pass?

njank 02-13-2014 06:50 PM

Going through a similar process now.

generally you can change a large number of options when you stop and restart. the log file just keeps track of your last location and which areas on the drive have and have not been tried (and the outcome). it will just read that file, and pick up where it left off.

I've never seen the Rescued actually drop. but I have noticed that on the drive I'm rescuing, the disk will go non-responsive if an error gets hit too often. (drive basically goes temporarily dead, not even appearing in an fdisk -l). When this happens, ddrescue doesn't know, and just gets an error on the read attempt. so it starts logging errors for each spot tested. My drive will come back to life a minute or so later, but in that time ddrescue will fill almost the entire remaining log with these false 'errors' (because each read is much faster when it's not actually reading anything).

After it's finished with trying to copy from all untried areas, ddrescue will then move into the next phase, splitting/trimming all the failed blocks. since almost all of your drive looks like failed blocks, it'll stay there for a while. I don't know exactly what it's doing there, but I imagine it could be slower than the 'copying untried blocks' stage.

Because my drive drops out so often, I use the -i and -s options to give it chunks to try at a time (start at 5GB, copy up to 5 GB, etc.) then if it drops out, it'll only fill that 5GB chunk with errors. If I come back later and see that, I can run the same command with a -A --retrim to mark all of those errors as 'not tried'. then set it to run again, maybe skipping to a slightly later section. As you can guess, it has turned running the program into a very hands-on process.

SO...It's possible that you're drive went non-responsive and ddrescue filled the log with a ton of 'errors' that may or may not be real. since they're filling almost the whole hard drive, you could clear them with the -A --retrim option and re-run the recover. it'll start trying to copy where the first error was. this can include actual bad sectors, however, which could cause your drive to drop out again. in that case you may want to set it to start at a different location with the -i option, or have it work backwards with the -R, etc.

If you want a better idea for what it's doing, download 'ddrescueview'. you can open the log file and it'll give you a visual display that it periodically updates while you're running ddrescue.

njank 02-13-2014 06:55 PM

forgot to add: if you use ddrescueview, the physical layout of the errors / rescued spots on the disk might give an indication of what happened.

if you have good sectors mixed in with the bad, then I guess the drive was at least partially responsive during the rescue. If it's one solid block of red, then maybe the drive dropped out.


All times are GMT -5. The time now is 09:25 AM.