0

I am running ddrescue, trying to copy my dying 2TB Seagate Baracuda harddrive to a new 4TB hard drive. Now, it has been running for 5 days now, and on the terminal screen I see there are some read errors. The rescue is about 33% at the moment. Here is the link to my original post for the background Original post.

Below is the today's ddrescue logfile:

# Mapfile. Created by GNU ddrescue version 1.26
# Command line: ddrescue -d -f -r3 /dev/sdb /dev/sdc sdc.log
# Start time:   2023-02-18 05:03:10
# Current time: 2023-02-23 10:44:03
# Copying non-tried blocks... Pass 1 (forwards)
# current_pos  current_status  current_pass
0x9873E60000     ?               1
#      pos        size  status
0x00000000  0x47AC630000  +
0x47AC630000  0x00010000  *
0x47AC640000  0x01320000  ?
0x47AD960000  0x479140000  +
0x4C26AA0000  0x00010000  *
0x4C26AB0000  0x01320000  ?
0x4C27DD0000  0x2FA860000  +
0x4F22630000  0x00010000  *
0x4F22640000  0x01320000  ?
0x4F23960000  0x1F7230000  +
0x511AB90000  0x00010000  *
0x511ABA0000  0x01320000  ?
0x511BEC0000  0x32780000  +
0x514E640000  0x00010000  *
0x514E650000  0x01320000  ?
0x514F970000  0xC5D00000  +
0x5215670000  0x00010000  *
0x5215680000  0x01320000  ?
0x52169A0000  0x111D50000  +
0x53286F0000  0x00010000  *
0x5328700000  0x01320000  ?
0x5329A20000  0x2067810000  +
0x7391230000  0x00010000  *
0x7391240000  0x01320000  ?
0x7392560000  0xA39120000  +
0x7DCB680000  0x00010000  *
0x7DCB690000  0x01320000  ?
0x7DCC9B0000  0x1AA74C0000  +
0x9873E70000  0x1394D2A6000  ?

Here is the output in the terminal: ddrescue terminal output

I am patient and letting it run for another week to finish copying. At the same time, I am anxious about the progress.. I am unclear about:

  1. '*' [failed block non-trimmed] in the log file, does it mean that some or all of the data in those areas/blocks are lost?
  2. Read errors: 10 [in terminal window]. How bad is this while 33% is rescued so far?

The plan is to make another copy from this intermediate copy and try to recover partition or data by using TestDisk later on the second copy drive. So, if this looks promising, then I should proceed with the plan.

3
  • 1
    Have you read the manual? It describes the algorithm. In particular the fragment about "Second phase; Trimming" states what will happen to non-trimmed blocks. Commented Feb 23, 2023 at 13:01
  • 1
    I did but honestly, I skipped the algorithm. Thanks for pointing out.
    – Irfan
    Commented Feb 23, 2023 at 13:51
  • Apparently, this is just first pass (stage) and it has marked the area as "failed block non-trimmed" in this run. And in second phase, ddrescue will attempt at it again, and later (after a couple more attempts) will be marked as a bad sector. If I got it right, then the log file doesn't say much at this time while it is still in Pass 1 stage.
    – Irfan
    Commented Feb 23, 2023 at 13:59

2 Answers 2

0
  1. '*' [failed block non-trimmed] in the log file, does it mean that some or all of the data in those areas/blocks are lost?

That is correct. Do not worry now. The untrimmed blocks do not justify fear.

  1. Read errors: 10 [in terminal window]. How bad is this while 33% is rescued so far?

It depends on which sectors are unreadable because the sectors are not equally important.

The best case is when the errors all belong to one file whose loss you can afford. This is most likely not the case.

The worst case is when the errors are within essential metadata structures. You will see this once you try accessing partitions with Testdisk.

If that fails you will need a recovery program that deals with the specific remains of the file systems on your partitions. If there is no usable meta data left over, Photorec might help you as last line of defense against data loss.

If you use the mapfile feature of ddrescue, the data are rescued very efficiently, (only the blocks needed are read). Also you may interrupt the rescue at any time and resume it later

That statement from the ddrescue manual quoted by harrymc is misleading and wrong!

What is "blocks needed"?! Only used blocks are needed. To understand what used blocks are you have to understand the partitioning schemes and file systems. That is not the case for ddrescue - it is working universally. It tries to read all blocks of the device that you adressed, not only the used ones but tries to avoid areas with lots of unreadable sectors.

0
0

What you call the logfile is actually the mapfile, which is used to keep track of what is still left to be done in subsequent runs of ddrescue.

You will find a detailed description in the GNU ddrescue Manual:

The basic operation of ddrescue is fully automatic. That is, you don't have to wait for an error, stop the program, restart it from a new position, etc.

If you use the mapfile feature of ddrescue, the data are rescued very efficiently, (only the blocks needed are read). Also you may interrupt the rescue at any time and resume it later at the same point. The mapfile is an essential part of ddrescue's effectiveness. Use it unless you know what you are doing.

The important points to retain :

  • The mapfile is the record-book of ddrescue
  • It's important to specify the same mapfile in all calls to ddrescue, so subsequent runs will not repeat salvage operations that already succeeded
  • The first ddrescue will copy all the easily salvaged sectors, so will logically be the slowest
  • Subsequent runs will attempt to recover the hard errors
  • Not all sectors need to be recovered, just enough to recover your data
  • If you wish to later employ other data-rescue programs, it will be more efficient to use the disk's image by ddrescue rather than the failing disk.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .