Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
August 3rd, 2013, 20:42
When a hard drive is failing, the consensus is that it should be imaged as quickly as possible. But imaging a large drive to retrieve a small amount of files (relative to the drive size) doesn’t seem very efficient. For instance a user has a 750GB drive and wants their pictures and documents off of it, which may be well less than 10GB. So imaging the drive takes time, and the longer the drive operates, the more likely it is to sustain further damage.
So now let’s say it is possible to read the file table, process it offline, and then go back and read only the files we really want. It would be much faster than a full image, but this would cause the drive heads to move around back and forth, as opposed to a sequential image read. At what point would it be worse to read the files vs doing a full image?
And before you all say that it should be imaged first so that you have something proper to work with, consider this… All the file reads (including the file table) would be logged (thanks to gnuddrescue), and with some work could be written to a new destination drive or image file. Meaning that all successful reads would only have to be done once. So any sectors of data read during the file recovery could be put on a new image and not have to be read again from the failing drive. So if needed, the drive imaging could be “resumed”.
So what is worse? Reading a long time to get a little data, or bouncing the head all over for a hopefully much shorter time to get the most desired data first?
August 3rd, 2013, 21:57
If you able to calculate which sectors belong to the files then you able to sort the LBAs and read them as sequential as possible
Professional DR imagers can do all of the described tasks
August 3rd, 2013, 23:03
Doomer wrote:If you able to calculate which sectors belong to the files then you able to sort the LBAs and read them as sequential as possible
Professional DR imagers can do all of the described tasks
The files could be sorted by order of the first sector of data, allowing for the most sequential read. Fragmented files would still cause a non-sequential read, but normally there shouldn't be a high number of fragmented files. So how significant is it to read as sequential as possible?
And what professional DR imagers are you speaking of?
August 4th, 2013, 5:42
Deepspar, PC3000 Data Extractor and Atola Imager can all do this, select the used and/or required data area and then sequentially sector clone the selected sectors only.
August 4th, 2013, 6:27
but this would cause the drive heads to move around back and forth, as opposed to a sequential image read.
nope
Imaging by MFT:
as
doomer &
pcimage mentioned, these will recover by MFT in a sequential scan, not by skipping back and forth.
Demo
Outerz0ne 6 - Hard Drive Kung Fu Magic 1 (2010)
http://www.youtube.com/watch?v=uLOmywCf ... E99C4A1381DDI starts at end of part 1 if you don't want the backstory.
August 4th, 2013, 9:40
This is old technology at this point. You always generate a bitmap and focus on the sectors that contain critical folders and files first.
August 4th, 2013, 9:58
digitalferret wrote:but this would cause the drive heads to move around back and forth, as opposed to a sequential image read.
nope
Imaging by MFT:
as
doomer &
pcimage mentioned, these will recover by MFT in a sequential scan, not by skipping back and forth.
Demo
Outerz0ne 6 - Hard Drive Kung Fu Magic 1 (2010)
http://www.youtube.com/watch?v=uLOmywCf ... E99C4A1381DDI starts at end of part 1 if you don't want the backstory.
I didn't watch the whole thing, but it seems about exactly what I am trying to do... except I am doing it low budget (no $10,000 equipment here). I am using ddrescue for all the reads, and writing my own software to do all the processing.
I think my question has been answered well enough that I will make sure that the reads are as sequential as possible
Powered by phpBB © phpBB Group.