gddrescue slow transfer, but no bad sectors [closed]
Clash Royale CLAN TAG#URR8PPP
I recently noticed my 2ndary internal HDD was having issues when I wanted to back up information to my external HDD. 1.4 TB out of the 2TB was being used. My transfers rates were plummeting to 0 and struggling to get data off. I started looking for what could be wrong, but guessed it was most likely my hard drive dying. I tried a SMART scan with chkdsk but it would slow down and halt around 30%. I've switched to trying out gddrescue as I repeatedly read that using data recovery app for Windows could cause more damage. I downloaded Kali for my usb drive and connected my old 2TB Toshiba harddrive by SATA cable, and installed a new 3TB WD harddrive by SATA cable to start a transfer.
This is what I used to start the scan.
ddrescue -f /dev/sda /dev/sdb /root/Desktop/log1.log
I got it up to 52% rescued during the first pass, and there have been no errors or bad sectors yet. So I'm not sure if this is right or not, but the transfer rate was barely avging at 10,000 B/s at this point.
I stopped it and started a reverse scan with
ddrescue -f -R /dev/sda /dev/sdb /root/Desktop/log1.log
From here it started off at a lowered speed first and has also dropped down to an avg of 10,000 B/s.
Is this normal during a first pass? If it is downloading this slow shouldn't it skip to the other sectors first to download and then come back to these slower sectors if they are bad during the first pass? Also for the "data rescued" portion is that actually already cloned into the new hard drive or does the operation need to fully complete to have that data in the hard drive?
data-recovery ddrescue
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
asked Jan 20 at 4:32
WAHWAH
1
closed as unclear what you're asking by Rui F Ribeiro, Thomas, Mr Shunz, msp9011, Archemar Jan 21 at 13:24
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I recently noticed my 2ndary internal HDD was having issues when I wanted to back up information to my external HDD. 1.4 TB out of the 2TB was being used. My transfers rates were plummeting to 0 and struggling to get data off. I started looking for what could be wrong, but guessed it was most likely my hard drive dying. I tried a SMART scan with chkdsk but it would slow down and halt around 30%. I've switched to trying out gddrescue as I repeatedly read that using data recovery app for Windows could cause more damage. I downloaded Kali for my usb drive and connected my old 2TB Toshiba harddrive by SATA cable, and installed a new 3TB WD harddrive by SATA cable to start a transfer.
This is what I used to start the scan.
ddrescue -f /dev/sda /dev/sdb /root/Desktop/log1.log
I got it up to 52% rescued during the first pass, and there have been no errors or bad sectors yet. So I'm not sure if this is right or not, but the transfer rate was barely avging at 10,000 B/s at this point.
I stopped it and started a reverse scan with
ddrescue -f -R /dev/sda /dev/sdb /root/Desktop/log1.log
From here it started off at a lowered speed first and has also dropped down to an avg of 10,000 B/s.
Is this normal during a first pass? If it is downloading this slow shouldn't it skip to the other sectors first to download and then come back to these slower sectors if they are bad during the first pass? Also for the "data rescued" portion is that actually already cloned into the new hard drive or does the operation need to fully complete to have that data in the hard drive?
data-recovery ddrescue
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
asked Jan 20 at 4:32
WAHWAH
1
closed as unclear what you're asking by Rui F Ribeiro, Thomas, Mr Shunz, msp9011, Archemar Jan 21 at 13:24
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
What part of the disk being bad you did not understand?
– Rui F Ribeiro
Jan 20 at 9:17
That's the thing, I'm assuming it's bad since the rate is low, but I'm not sure if that is normal or not for running ddrescue. It hasn't marked any bad sectors or errors yet either so it is confusing me.
– WAH
Jan 20 at 9:56
add a comment |
I recently noticed my 2ndary internal HDD was having issues when I wanted to back up information to my external HDD. 1.4 TB out of the 2TB was being used. My transfers rates were plummeting to 0 and struggling to get data off. I started looking for what could be wrong, but guessed it was most likely my hard drive dying. I tried a SMART scan with chkdsk but it would slow down and halt around 30%. I've switched to trying out gddrescue as I repeatedly read that using data recovery app for Windows could cause more damage. I downloaded Kali for my usb drive and connected my old 2TB Toshiba harddrive by SATA cable, and installed a new 3TB WD harddrive by SATA cable to start a transfer.
This is what I used to start the scan.
ddrescue -f /dev/sda /dev/sdb /root/Desktop/log1.log
I got it up to 52% rescued during the first pass, and there have been no errors or bad sectors yet. So I'm not sure if this is right or not, but the transfer rate was barely avging at 10,000 B/s at this point.
I stopped it and started a reverse scan with
ddrescue -f -R /dev/sda /dev/sdb /root/Desktop/log1.log
From here it started off at a lowered speed first and has also dropped down to an avg of 10,000 B/s.
Is this normal during a first pass? If it is downloading this slow shouldn't it skip to the other sectors first to download and then come back to these slower sectors if they are bad during the first pass? Also for the "data rescued" portion is that actually already cloned into the new hard drive or does the operation need to fully complete to have that data in the hard drive?
data-recovery ddrescue
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
asked Jan 20 at 4:32
WAHWAH
1
I recently noticed my 2ndary internal HDD was having issues when I wanted to back up information to my external HDD. 1.4 TB out of the 2TB was being used. My transfers rates were plummeting to 0 and struggling to get data off. I started looking for what could be wrong, but guessed it was most likely my hard drive dying. I tried a SMART scan with chkdsk but it would slow down and halt around 30%. I've switched to trying out gddrescue as I repeatedly read that using data recovery app for Windows could cause more damage. I downloaded Kali for my usb drive and connected my old 2TB Toshiba harddrive by SATA cable, and installed a new 3TB WD harddrive by SATA cable to start a transfer.
This is what I used to start the scan.
ddrescue -f /dev/sda /dev/sdb /root/Desktop/log1.log
I got it up to 52% rescued during the first pass, and there have been no errors or bad sectors yet. So I'm not sure if this is right or not, but the transfer rate was barely avging at 10,000 B/s at this point.
I stopped it and started a reverse scan with
ddrescue -f -R /dev/sda /dev/sdb /root/Desktop/log1.log
From here it started off at a lowered speed first and has also dropped down to an avg of 10,000 B/s.
Is this normal during a first pass? If it is downloading this slow shouldn't it skip to the other sectors first to download and then come back to these slower sectors if they are bad during the first pass? Also for the "data rescued" portion is that actually already cloned into the new hard drive or does the operation need to fully complete to have that data in the hard drive?
data-recovery ddrescue
data-recovery ddrescue
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
asked Jan 20 at 4:32
WAHWAH
1
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
asked Jan 20 at 4:32
WAHWAH
1
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
edited Jan 20 at 9:16
Rui F Ribeiro
39.9k1479135
39.9k1479135
asked Jan 20 at 4:32
WAHWAH
1
asked Jan 20 at 4:32
WAHWAH
1
asked Jan 20 at 4:32
WAHWAH
1
1
closed as unclear what you're asking by Rui F Ribeiro, Thomas, Mr Shunz, msp9011, Archemar Jan 21 at 13:24
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by Rui F Ribeiro, Thomas, Mr Shunz, msp9011, Archemar Jan 21 at 13:24
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
What part of the disk being bad you did not understand?
– Rui F Ribeiro
Jan 20 at 9:17
That's the thing, I'm assuming it's bad since the rate is low, but I'm not sure if that is normal or not for running ddrescue. It hasn't marked any bad sectors or errors yet either so it is confusing me.
– WAH
Jan 20 at 9:56
add a comment |
What part of the disk being bad you did not understand?
– Rui F Ribeiro
Jan 20 at 9:17
That's the thing, I'm assuming it's bad since the rate is low, but I'm not sure if that is normal or not for running ddrescue. It hasn't marked any bad sectors or errors yet either so it is confusing me.
– WAH
Jan 20 at 9:56
What part of the disk being bad you did not understand?
– Rui F Ribeiro
Jan 20 at 9:17
What part of the disk being bad you did not understand?
– Rui F Ribeiro
Jan 20 at 9:17
That's the thing, I'm assuming it's bad since the rate is low, but I'm not sure if that is normal or not for running ddrescue. It hasn't marked any bad sectors or errors yet either so it is confusing me.
– WAH
Jan 20 at 9:56
That's the thing, I'm assuming it's bad since the rate is low, but I'm not sure if that is normal or not for running ddrescue. It hasn't marked any bad sectors or errors yet either so it is confusing me.
– WAH
Jan 20 at 9:56
add a comment |
1 Answer
1
active
oldest
votes
The behavior of ddrescue will depend on the behavior of the disk itself when there are read errors.
Some disks will just make a few attempts for each read request, and report an error if the disk's internal logic indicates the results were most likely erroneous. This allows ddrescue and similar utilities to make multiple attempts and analyze the results of each attempt separately, until they can get a statistically high confidence that all the requested data was read correctly.
Other disks will attempt to do that on their own: when given just one request to read a block of data that contains errors, the disk will keep attempting to read it very many times, only returning the data when the disk's internal diagnostics indicate the read attempt was most likely successful. When the disk finally gets a successful read, it returns the data to the application, without necessarily reporting any errors.
Of course, the fact that the disk itself massively multiplies the number of read attempts per failing block means that the disk will be extremely slow to access.
Marking a failing disk block as bad normally happens only with write operations. If read operations would also detect bad blocks, that would mean the system would essentially decide on its own that a specific block of data is no longer recoverable, and would then replace it with a spare block full of zeroes. That would make any subsequent data recovery attempts much harder: you would need special software or even hardware to override the bad block replacement logic in the disk itself to get another chance to recover data from the actual bad block instead of just reading the empty replacement block.
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The behavior of ddrescue will depend on the behavior of the disk itself when there are read errors.
Some disks will just make a few attempts for each read request, and report an error if the disk's internal logic indicates the results were most likely erroneous. This allows ddrescue and similar utilities to make multiple attempts and analyze the results of each attempt separately, until they can get a statistically high confidence that all the requested data was read correctly.
Other disks will attempt to do that on their own: when given just one request to read a block of data that contains errors, the disk will keep attempting to read it very many times, only returning the data when the disk's internal diagnostics indicate the read attempt was most likely successful. When the disk finally gets a successful read, it returns the data to the application, without necessarily reporting any errors.
Of course, the fact that the disk itself massively multiplies the number of read attempts per failing block means that the disk will be extremely slow to access.
Marking a failing disk block as bad normally happens only with write operations. If read operations would also detect bad blocks, that would mean the system would essentially decide on its own that a specific block of data is no longer recoverable, and would then replace it with a spare block full of zeroes. That would make any subsequent data recovery attempts much harder: you would need special software or even hardware to override the bad block replacement logic in the disk itself to get another chance to recover data from the actual bad block instead of just reading the empty replacement block.
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
add a comment |
The behavior of ddrescue will depend on the behavior of the disk itself when there are read errors.
Some disks will just make a few attempts for each read request, and report an error if the disk's internal logic indicates the results were most likely erroneous. This allows ddrescue and similar utilities to make multiple attempts and analyze the results of each attempt separately, until they can get a statistically high confidence that all the requested data was read correctly.
Other disks will attempt to do that on their own: when given just one request to read a block of data that contains errors, the disk will keep attempting to read it very many times, only returning the data when the disk's internal diagnostics indicate the read attempt was most likely successful. When the disk finally gets a successful read, it returns the data to the application, without necessarily reporting any errors.
Of course, the fact that the disk itself massively multiplies the number of read attempts per failing block means that the disk will be extremely slow to access.
Marking a failing disk block as bad normally happens only with write operations. If read operations would also detect bad blocks, that would mean the system would essentially decide on its own that a specific block of data is no longer recoverable, and would then replace it with a spare block full of zeroes. That would make any subsequent data recovery attempts much harder: you would need special software or even hardware to override the bad block replacement logic in the disk itself to get another chance to recover data from the actual bad block instead of just reading the empty replacement block.
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
add a comment |
The behavior of ddrescue will depend on the behavior of the disk itself when there are read errors.
Some disks will just make a few attempts for each read request, and report an error if the disk's internal logic indicates the results were most likely erroneous. This allows ddrescue and similar utilities to make multiple attempts and analyze the results of each attempt separately, until they can get a statistically high confidence that all the requested data was read correctly.
Other disks will attempt to do that on their own: when given just one request to read a block of data that contains errors, the disk will keep attempting to read it very many times, only returning the data when the disk's internal diagnostics indicate the read attempt was most likely successful. When the disk finally gets a successful read, it returns the data to the application, without necessarily reporting any errors.
Of course, the fact that the disk itself massively multiplies the number of read attempts per failing block means that the disk will be extremely slow to access.
Marking a failing disk block as bad normally happens only with write operations. If read operations would also detect bad blocks, that would mean the system would essentially decide on its own that a specific block of data is no longer recoverable, and would then replace it with a spare block full of zeroes. That would make any subsequent data recovery attempts much harder: you would need special software or even hardware to override the bad block replacement logic in the disk itself to get another chance to recover data from the actual bad block instead of just reading the empty replacement block.
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
The behavior of ddrescue will depend on the behavior of the disk itself when there are read errors.
Some disks will just make a few attempts for each read request, and report an error if the disk's internal logic indicates the results were most likely erroneous. This allows ddrescue and similar utilities to make multiple attempts and analyze the results of each attempt separately, until they can get a statistically high confidence that all the requested data was read correctly.
Other disks will attempt to do that on their own: when given just one request to read a block of data that contains errors, the disk will keep attempting to read it very many times, only returning the data when the disk's internal diagnostics indicate the read attempt was most likely successful. When the disk finally gets a successful read, it returns the data to the application, without necessarily reporting any errors.
Of course, the fact that the disk itself massively multiplies the number of read attempts per failing block means that the disk will be extremely slow to access.
Marking a failing disk block as bad normally happens only with write operations. If read operations would also detect bad blocks, that would mean the system would essentially decide on its own that a specific block of data is no longer recoverable, and would then replace it with a spare block full of zeroes. That would make any subsequent data recovery attempts much harder: you would need special software or even hardware to override the bad block replacement logic in the disk itself to get another chance to recover data from the actual bad block instead of just reading the empty replacement block.
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
answered Jan 21 at 9:17
telcoMtelcoM
17k12347
17k12347
add a comment |
add a comment |
What part of the disk being bad you did not understand?
– Rui F Ribeiro
Jan 20 at 9:17
That's the thing, I'm assuming it's bad since the rate is low, but I'm not sure if that is normal or not for running ddrescue. It hasn't marked any bad sectors or errors yet either so it is confusing me.
– WAH
Jan 20 at 9:56