Question #671230 “recovered data unreadable” : Questions : DDRescue-GUI

Revision history for this message

Hamish McIntyre-Bhatty (hamishmb) said on 2018-07-31:

#1

Hi,

Is that a SMART error?

Yes, /dev/sdc3 will have been overwritten, so any data that was there is now probably gone - hopefully you were aware that this would happen; the GUI does give a warning when you recover to a file. Did you quit the recovery, or did it stop of its own accord?

If you've recovered 61% of your source drive, chances are that there is readable data there, but the filesystem corrupted when the drive failed. You can probably use a tool like photorec, or others, to read from your destination drive /dev/sdc3 and write any files found to another drive or partition.

A more conventional way of doing this would be to recover to a file, which is a bit safer in terms of not accidentally overwriting data, and it's easier to store the data if you need to use a tool like photorec, but as long as you have another (3rd) drive/partition to store the data to, you'll be fine :).

Hope this helps,
Hamish

Revision history for this message

DEAN GAUDREAU (deano2018) said on 2018-07-31:

#2

Hamish,
Thanks for the timely reply. When I started seeing performance issues with this Tosheba 2tb drive I ran smartctl --all /dev/sdb which has 2 1tb partitions labeled Data 4 and Data 5 I have recovered a lot of data from Data 4 using Dolphin move and in some case copy when I had mounted the drive read only. I purchased a new 3 tb drive and partitioned it into 3 1 tb partitions labeled Data 1 Data 2 and Data 3. I was trying to recover Data 4 (sdb1) to Data 3(sdc3) since I had used Data 1(sdc1) as the target for my move and copy efforts. The plan was to move the recovered (now good data) to Data 1(sdc1) completing the restore process. I could then format sdc3 and repeat the process for the data on sdb2 (Data 5).

It started fast and then slowed to a craw so I quit after a few days. Some interesting things happened: I now have 2 Data 4's. The original which I can mount and look at with Dolphin and one that is unmountable with an name of Data 3 and a label of Data 4.I let photorec run for a while on sdc3 and it recovered some files, but the recover files (mostly videos) had the same problem as the originals. The would go to garbage or freeze using vlc. I suspect that the bad blocks that ddrescue skipped were ones that were in the video file and that no data is just as bad as corrupted dats in a video file.
I was trying to use ddrecue-GUI to get more because it was very tedious to try to move files when apparently read errors caused the system to hang or go really slow. I would abort the move and try another (usually at the folder level).
I used 0 retries because I wanted to get as much as possible as fast as possible and I thought that ddrescue would just skip stuff if it ran into bad blocks there by automating the process. None of the data on either of these partitions is critical but is desirable.
The file system on Data 4 seems to be intact ( I can see all the folders and enclosed files) I wonder if I could use a script that would access file names and feed them to ddrescue and and have ddrescue automatically abort and go to the next file if it found even one bad block. Alternatively, if I could run ddrescue at the folder level I could at least recover files in directories with no bad blocks. This of coarse would not work for deleted files, but I' not trying to recover them anyway. I don't know why I would want to recover any file (video or other) that had bad data in it.
How a file system keeps track of the mapping data in a file to to the physical location of the blocks on the HDD PFM (**** ******* Magic)
Regards,

Dean
On Tuesday, July 31, 2018, 12:22:32 PM EDT, Hamish McIntyre-Bhatty <email address hidden> wrote:

Your question #671230 on DDRescue-GUI changed:
https://answers.launchpad.net/ddrescue-gui/+question/671230

Assignee: None => Hamish McIntyre-Bhatty

--
You received this question notification because you asked the question.

Hamish,
Thanks for the timely reply.  When I started seeing performance issues with this Tosheba 2tb drive I ran smartctl --all /dev/sdb which has 2 1tb partitions labeled Data 4 and Data 5 I have recovered a lot of data from Data 4 using Dolphin move and in some case copy when I had mounted the drive read only. I purchased a new 3 tb drive and partitioned it into 3 1 tb partitions labeled Data 1 Data 2 and Data 3.  I was trying to recover Data 4 (sdb1) to Data 3(sdc3) since I had used Data 1(sdc1) as the target for my move and copy efforts.  The plan was to move the recovered (now good data) to Data 1(sdc1) completing the restore process.  I could then format sdc3 and repeat the process for the data on sdb2 (Data 5).

It started fast and then slowed to a craw so I quit after a few days.  Some interesting things happened:  I now have 2 Data 4's.  The original which I can mount and look at with Dolphin and one that is unmountable with an name of Data 3 and a label of Data 4.I let photorec run for a while on sdc3 and it recovered some files, but the recover files (mostly videos) had the same problem as the originals.  The would go to garbage or freeze using vlc.  I suspect that the bad blocks that ddrescue skipped were ones that were in the video file and that no data is just as bad as corrupted dats in a video file.
I was trying to use ddrecue-GUI to get more because it was very tedious to try to move files when apparently read errors caused the system to hang or go really slow.  I would abort the move and try another (usually at the folder level).
I used 0 retries because I wanted to get as much as possible as fast as possible and I thought that ddrescue would just skip stuff if it ran into bad blocks there by automating the process.  None of the data on either of these partitions is critical but is desirable.
The file system on Data 4 seems to be intact ( I can see all the folders and enclosed files)  I wonder if I could use a script that would access file names and feed them to ddrescue and and have ddrescue automatically abort and go to the next file if it found even one bad block.  Alternatively, if I could run ddrescue at the folder level I could at least recover files in directories with no bad blocks.  This of coarse would not work for deleted files, but I' not trying to recover them anyway.  I don't know why I would want to recover any file (video or other) that had bad data in it.
How a file system keeps track of the mapping data in a file to to the physical location of the blocks on the HDD PFM (**** ******* Magic)
Regards,

Dean
    On Tuesday, July 31, 2018, 12:22:32 PM EDT, Hamish McIntyre-Bhatty <question671230@answers.launchpad.net> wrote:  
 
 Your question #671230 on DDRescue-GUI changed:
https://answers.launchpad.net/ddrescue-gui/+question/671230

Assignee: None => Hamish McIntyre-Bhatty

-- 
You received this question notification because you asked the question.

Revision history for this message

Hamish McIntyre-Bhatty (hamishmb) said on 2018-08-01:

#3

Hi Dean,

I see. Glad you didn't lose any data on your destination drive.

Yeah, recovering the data from the damaged areas of the disk is usually slow. You could go file by file with ddrescue, but there's not a lot of reasons to do that, because it's more labour intensive than just recovering the whole device/partition, like you have been. What stage did you get to? Are you still on "Copying non-tried blocks"?

The reason to recover files with corrupted/unreadable sectors is that ddrescue has a variety of methods of getting unreadable data off disks, but it just takes a long time. If you let it run for a while longer, it might start to pull data off the damaged areas of the disk, making your videos more playable - this is why a tool like ddrescue is helpful, primarily. You can have it abort when there is a read error, but because of the above, it's generally not what you want. The reason you still have the glitches/freezes playing the videos is because you haven't yet recovered the harder-to-read data, so it's missing from the videos.

Of course, some of the data that was unreadable may have corrupted, but the likelihood is at least some of it won't be - it's worth persevering if you have time to let it run, and then having a look again. As long as you saved a log file, you can restart the recovery from where you left off with the same input, output and log files.

Note: Another thing that might help is trying different settings in the settings window, particularly the read backwards option may speed things up for a while.

Essentially, it's about how long you are willing to wait, and how important the data is - the longer you let it run, the more data you'll get back. You might eventually even get all of it back! There may be long periods where it doesn't seem to do anything, but it will eventually get past the completely unreadable parts of the disk.

To summarise all that, I would recommend you let it run for a bit longer and see what happens. This will work as long as you haven't written anything to the destination drive (/dev/sdc3?). How slow was it going?

Hope this helps,
Hamish

Hi Dean,

I see. Glad you didn't lose any data on your destination drive.

Yeah, recovering the data from the damaged areas of the disk is usually slow. You could go file by file with ddrescue, but there's not a lot of reasons to do that, because it's more labour intensive than just recovering the whole device/partition, like you have been. What stage did you get to? Are you still on "Copying non-tried blocks"?

The reason to recover files with corrupted/unreadable sectors is that ddrescue has a variety of methods of getting unreadable data off disks, but it just takes a long time. If you let it run for a while longer, it might start to pull data off the damaged areas of the disk, making your videos more playable - this is why a tool like ddrescue is helpful, primarily. You can have it abort when there is a read error, but because of the above, it's generally not what you want. The reason you still have the glitches/freezes playing the videos is because you haven't yet recovered the harder-to-read data, so it's missing from the videos.

Of course, some of the data that was unreadable may have corrupted, but the likelihood is at least some of it won't be - it's worth persevering if you have time to let it run, and then having a look again. As long as you saved a log file, you can restart the recovery from where you left off with the same input, output and log files.

Note: Another thing that might help is trying different settings in the settings window, particularly the read backwards option may speed things up for a while.

Essentially, it's about how long you are willing to wait, and how important the data is - the longer you let it run, the more data you'll get back. You might eventually even get all of it back! There may be long periods where it doesn't seem to do anything, but it will eventually get past the completely unreadable parts of the disk.

To summarise all that, I would recommend you let it run for a bit longer and see what happens. This will work as long as you haven't written anything to the destination drive (/dev/sdc3?). How slow was it going?

Hope this helps,
Hamish

Revision history for this message

DEAN GAUDREAU (deano2018) said on 2018-08-01:

#4

just restarted but would not let me go backwards.

On Wednesday, August 1, 2018, 8:03:42 AM EDT, Hamish McIntyre-Bhatty <email address hidden> wrote:

Your question #671230 on DDRescue-GUI changed:
https://answers.launchpad.net/ddrescue-gui/+question/671230

Status: Open => Answered

Hamish McIntyre-Bhatty proposed the following answer:
Hi Dean,

I see. Glad you didn't lose any data on your destination drive.

Yeah, recovering the data from the damaged areas of the disk is usually
slow. You could go file by file with ddrescue, but there's not a lot of
reasons to do that, because it's more labour intensive than just
recovering the whole device/partition, like you have been. What stage
did you get to? Are you still on "Copying non-tried blocks"?

The reason to recover files with corrupted/unreadable sectors is that
ddrescue has a variety of methods of getting unreadable data off disks,
but it just takes a long time. If you let it run for a while longer, it
might start to pull data off the damaged areas of the disk, making your
videos more playable - this is why a tool like ddrescue is helpful,
primarily. You can have it abort when there is a read error, but because
of the above, it's generally not what you want. The reason you still
have the glitches/freezes playing the videos is because you haven't yet
recovered the harder-to-read data, so it's missing from the videos.

Of course, some of the data that was unreadable may have corrupted, but
the likelihood is at least some of it won't be - it's worth persevering
if you have time to let it run, and then having a look again. As long as
you saved a log file, you can restart the recovery from where you left
off with the same input, output and log files.

Note: Another thing that might help is trying different settings in the
settings window, particularly the read backwards option may speed things
up for a while.

Essentially, it's about how long you are willing to wait, and how
important the data is - the longer you let it run, the more data you'll
get back. You might eventually even get all of it back! There may be
long periods where it doesn't seem to do anything, but it will
eventually get past the completely unreadable parts of the disk.

To summarise all that, I would recommend you let it run for a bit longer
and see what happens. This will work as long as you haven't written
anything to the destination drive (/dev/sdc3?). How slow was it going?

Hope this helps,
Hamish

--
If this answers your question, please go to the following page to let us
know that it is solved:
https://answers.launchpad.net/ddrescue-gui/+question/671230/+confirm?answer_id=2

If you still need help, you can reply to this email or go to the
following page to enter your feedback:
https://answers.launchpad.net/ddrescue-gui/+question/671230

You received this question notification because you asked the question.

just restarted but would not let me go backwards.

On Wednesday, August 1, 2018, 8:03:42 AM EDT, Hamish McIntyre-Bhatty <question671230@answers.launchpad.net> wrote:  
 
 Your question #671230 on DDRescue-GUI changed:
https://answers.launchpad.net/ddrescue-gui/+question/671230