Help using ddrutility
LINUX based utility for use with gnuddrescue to aid with data recovery
Brought to you by:
maximus57
Menu
▾
▴
If you put the hard drive in the computer, I definitely recommend the -d option. It will not speed up good reads, but it will process the error sectors about 3 times faster. Plus if you don't us the -d option the returned errors are in block size of 8 sectors, so a single sector error will return 8 bad sectors. When it comes to the MFT, that can make a big difference, every sector counts!
As for my passthrough patch, since you already have done much recovery, and it has already marked areas as non-trimmed, I don't think it will help you much. It works best if used from the very beginning of the recovery. I think the -d option would be just as good for you. Ddrescue 1.19 has many good improvements, but again they work best from the beginning of the recovery. I am not sure if you would see any real advantage now over 1.17. You might as well stick with 1.17.
Thank you, that's really helpful. I will put the hard drive in the computer and use the -d and let you know later. Thanks again.
Damaged drive is now in laptop.
Have noticed that the general long term recovery rate is down below 100 kB/s and was higher at 130+ kB/s so I'm wondering if the drive is gradually failing more. Now trying to recover the mtf, invoked with:
sudo ddrescue -d -v /dev/sda cmsimage.dd rescue.log -m mft_logfile
and for the first 10 mins it hasn't moved:
GNU ddrescue 1.17
About to copy 286035 kBytes from /dev/sda to /home/ubuntu/Desktop/CMS-raw-image-link/cmsimage.dd
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
Initial status (read from logfile)
rescued: 185982 kB, errsize: 100 MB, errors: 3
Current status
rescued: 185982 kB, errsize: 100 MB, current rate: 0 B/s
ipos: 4010 MB, errors: 3, average rate: 0 B/s
opos: 4010 MB, time since last successful read: 10 m
Splitting failed blocks...
Does it make sense to limit the number of retries (-r1)?
Using -r1 will actually cause it to retry all the bad spots, and you don't want to do that right now! It is in the splitting phase right now for the mft domain. That means it is reading the bad areas one sector at a time to try to get data. 100MB is a lot of sectors to read when many of them are bad.
As I stated earlier, you may wish to finish with the rest of the normal recovery copy phase like you were doing since it was still reading. By trying hard in a damaged spot it is possible to cause further damage to the head. It is a hard decision whether to focus on the mft now since it is so important, or go on with reading the rest of the disk first since it was reading but risk it getting worse and not being able to get the rest of the mft later. If it is not getting any good data from the mft right now, then I would lean towards getting the rest of the disk since you will likely have to scan the disk for files anyway with the mft being that trashed.
Do you see why data recovery isn't always an exact science? You have to make decisions based on judgment calls, not knowing exactly what the drive is going to do. I con only supply my opinion on how to proceed, and it might not be right.
You have been brilliant. Thank you. I have no experience but am enjoying giving this recovery a try. I am going to run with your suggestion to recover the rest of the disk first and just see how it goes.
Is it possible to run ddrescue in two terminal windows simultaneously - one making the disk image and the other filling zeros on a copy of the image? Will it slow everything down?
I've seen your logfile ant strongly advise you to copy your drive reversed (-R key) because it seems that your drive got some scratches in outer area (that is beginning of the drive). If you will try to re-read bad areas you can destroy read elements (head assy replace needed) or fill G-list of your drive that can be fatal if it is, say, Seagate F3 series (when G-list is completely filled at these drives and they meet one more bad block they can fall in "not ready" state until power cycle so you need turn power on-off and drive can work again until next bad block. This can be fixed via drive's UART or by special software but it is more difficult than avoid that). WDC are also veeeery sloooow when they facing many relocation actions so try to read out undamaged areas first. Trying to maximally read out MFT is critical if you are sure that your files are mostly fragmented so you can not recover it by raw scanning at all. You can try to read reverse all the drive without trimming bad areas (-n -N) and then try to re-read mft by maximum. If you use different logfiles to read mft and all drive, be very careful to not zero-fill mft!
The drive is a WD black drive 500GB - if that makes any difference. I have tried -R several times but it is really slow. Much slower than going forwards. So I have tended to stick with the forward direction.
Thanks for warning about rereading bad areas.
@olegkrutov
Your input in this is very welcome! I am trying to give the best advice that I can from the information presented, and my somewhat limited knowledge. Unfortunately we cannot be there to make judgment calls on the fly.
I believe he is running ddrescue 1.17 again at this time (and the rescue was started with 1.17), which means there is only a -n option and no -N option. This means it will still try to trim, which is why I said to stop when it says trimming failed blocks. It could be beneficial to use 1.19 to avoid this. Since he was using 1.17 all the skipped areas have been marked as non-trimmed instead of non-tried. As long as the -n option is used it will not try to read the beginning of the disk again until the copy phase is complete and it starts the trimming phase. Using version 1.19 with both the -n and -N options it would stop before trying to read the beginning of the disk again.
He should be using the same rescue logfile for all recovery attempts including using domains if he read what I said correctly. I fully agree that the rest of the disk should be rescued first. However, based on the logfile I think that it should be good to finish reading forward (until it gets to the end and starts trimming) since the current read position is well into the disk and not encountering errors.
Maybe when it gets to the point of trimming it should be stopped and an attempt to see what can be recovered from the image should be done before trying to get the rest of the mft or any further data. It appears he is planning on working with a copy of the recovered image, keeping the original image unchanged so that the recovery can be resumed again for further attempts.
Because the recovery was/is being done with 1.17, there are a few large areas that were skipped and marked as non-trimmed. There could be readable data at the end of those areas, but in this case that would require custom read commands (and in reverse), and I do not have the time to help with that. There is also one big 1GB non-trimmed section that I cannot explain (do not see the skipping signature in it) which could yield a fair amount of good read data yet. But again, to read requires a custom command.
I believe it should be possible to run a second window of ddrescue like that. Just to be clear, you need to run it against a copy of the image AND a copy of the logfile (which should have been copied at the same time so they match). You don't want to have ddrescue running twice against the same drive, image, or logfile. I do not know how much it will slow it down since your drive reads are so slow already. You won't know until you try.
Update:
Recovery continued with ddrescue 1.17, drive in laptop and using -n. Latest rescue log and mft log attached. 14GB still to recover, expected to finish in circa 12-14hrs.
From previous advice, I plan to:
- copy the image and log file
- recover in reverse
- recover the mft
- recover other non-trimmed, non-scraped areas
Does this sound sensible? What specific commands should I use with ddrescue to recover the mft or other areas?
copy the image and log file
Yes, very good idea. Make an extra copy of the log file for the editing I mention below.
recover in reverse
There is a problem with that. Once ddrescue 1.17 hits the trimming phase it jumps all over and the reverse option does not do anything. This is why I said it would be custom commands to recover certain parts. However, I came up with an idea for you. Using some spreadsheet magic I sorted out the top large non-trimmed areas. They are all over 1 MB in size. The top one is 1 GB, and you need to focus on that one first! I have attached it as a text file. Note that I had to drop the 0x from all the hex to get it to sort properly.
You need to find the the lines in your logfile that match what I have attached. Then edit it and change the "*" to "?" on each of those lines. This will mark those areas as non-tried so ddrescue will try to read them again in the normal copy phase. You should do the top line first and by itself as it is most likely to have good data and is not in a real bad spot. Add the reverse option to your ddrescue command. When it is done with the copy phase and starts the trimming phase then stop it. Then change the rest of the lines at once and run the command again, again stopping it when it starts trimming.
After that going for the mft and the rest of the data sounds reasonable. I would suspect that at some point in time it could end up spending too much time on the bad "scratched" area and finish killing the head and start turning data into dust. Get what you can and hope for the best.
Also make sure to use the --direct option for the trimming and splitting phase. Without it the errors are limited to 8 sector block size instead of single sectors.
Maximus57 thank you for your guidance and suggesting how I tackle the rest of the recovery. The image finished a few hours ago and so far I have left it because it started trimming the 1GB block from the end. I will keep an eye on it and if it continues trimming the 1GB block leave it otherwise follow your approach. Thank you for the text file.
BTW if you want ddrescue (hmmm... it seems that it is about 1.19) to copy drive in reversed order from_last_unprocessed_LBA and not from last place marked in logfile -- just place 0 instead of this last place in your logfile. That is first non_comment line in logfile, there is "# current pos current status" above it. Without it, even --input-position is ignored with -R key.