[Recuva deep scan takes days]

Thanks Alan_B and Augeas.

 

To be honest Kevin, I think you're going about it the wrong way. To run Recuva against a RAW partition, which is not supported (I'm surprised it actually runs) and to expect some relevant results, is rather optimistic. I would try to get the partition back to a recognised file organisation first. How can the timings be relevant?

 

But I might be proved wrong. I can't offer any advice as this is way into the unknown.

 

Since Augeas suggested RAW is not supported by Recuva, I decided to try two other tools which do explicitly support RAW partitions -- iCare Data Recovery and Easeus Data Recovery Wizard. But the result was the same kind of slow performance -- multiple day wait times. So I gave up on those, as well.

 

From there, I sought some way to "get the partition back to a recognised file organisation" as Augeas suggested. I went with the testdisk routine available on the PartedMagic as described by James Litten.

 

When testdisk began showing multiple disk read errors, I took the advice to download and run a utility to test the health of the hard drive itself, namely HDTune.

 

The HDTune error scan on this disk shows massive damage, 70% damaged blocks in the first 4 GB, and still counting.

 

This escalates the disk's case beyond the scope of the Recuva forum, as my only hope at this point is to send in the disk to a professional recovery company. The data I'm trying to recover is probably not worth that expense.

 

Thanks again to everyone for your help and advice.

 

Kevin

[Recuva deep scan takes days]

Currently back to the state before the restart:

 

Current progress: 0%, 175848 file(s) found

Estimated time left: 12 days

 

Thanks,

Kevin

[Recuva deep scan takes days]

Thank you, Alan_B, Augeas, and Nergal.

 

I'm posting a screenshot of Windows Disk Management. The disk in question is "Disk 3", which shows up in Recuva as "G:".

 

The Recuva dialog currently shows:

 

Stage 1 of 3: Scanning drive for deleted files

Current progress: 0%, 162769 file(s) found

Calculating time left...

 

I'm thankful for all the input and help on this thread, and understand the scan and recovery of the damaged disk may take days or weeks and may not be fully successful (by Recuva, or perhaps any other disk recovery consumer software).

 

Kevin

[Recuva deep scan takes days]

Thanks for your responses.

 

The drive was running Windows 8 on a computer that froze and subsequently lost power abruptly. I suspect a loose RAM board I found was the cause of the freeze. The abrupt loss of power was user related (non-technical user). Upon power up, the computer would not boot, and a disk restore using a Linux-based "Restore MFT/boot sector" tool failed because the operating system could no longer be found on the drive.

 

Additionally to this, I'll mention that the Windows 8 computer ran unusually slowly even when it was purchased new. Now that I've replaced the hard drive on that system, it is quite speedy. So it occurs to me that that system's slowness may also have been related to the hard drive I'm currently trying to scan, i.e., that it may have always been a defective hard drive.

 

Trying to recover some of the user's personal files with "non-deleted files" set did not find the files. I assume the files are still there written on some sectors, but no index or pointer to them is available anymore. That's the case "deep scan" is meant to detect and help resolve. They were not deleted files.

 

The filesystem type that shows up in "Computer Management > Storage > Disk Management" in Windows 7 is neither NTFS nor FAT32. It is: RAW. It used to be NTFS as best I can guess, considering it was a recently purchased Windows 8 machine.

 

The 10 MB/s - 100 MB/s read speeds mentioned by Alan_B would be wonderful; what I'm observing is in the 10 KB/s range, i.e., KB/s instead of MB/s.

 

Thanks again.

 

Kevin

[Recuva deep scan takes days]

To eliminate the possibility of the USB 3.0 controller being the problem, I decided to cancel the run. I replaced the controller completely with a different USB 3.0 controller and cable, and started over. I also disabled the laptop's antivirus program.

 

I restarted the run and observed initial disk throughput of > 1 MBytes/s.

 

Now the situation is back to the same as in the previous run with read throughput of about 30 KBytes/s.

 

From the pattern of disk reading, this low throughput is not the result of a steady attempt to read from the disk; rather, the reading is being done in small spurts.

 

At times, the reads are very short and the throughput goes down to about 5 KBytes/s.

 

The new run is showing:

 

Stage 1 of 3: Scanning drive for deleted files

Current progress: 0%, 162769 file(s) found

Calculating time left...

 

Kevin

[Recuva deep scan takes days]

I'm using a USB 3.0 external controller with a USB 3.0 cable connected to a USB 2.0 port on this laptop which has a reliable, fast throughput (USB 2.0 speed). The speeds I'm seeing above, around 30 KBytes/sec are about one sixth the speed of USB 1.0.

 

I previously began this process on a different laptop using a USB 3.0 port (3.0 controller + 3.0 cable + 3.0 port), but aborted it because it was so slow (similar estimated times) and tried again on the currently running laptop.

 

I'm wondering if someone with technical experience might be able to help me understand if there is likely a problem with the USB 3.0 controller, either on the USB side or on the hard-drive side. Should I consider swapping out the current controller for a different spare controller?

 

Assuming the USB connection is working correctly, are there failure modes or fallback modes on the controller/harddrive side that would explain such low throughput?

 

Current Estimated time left is now 27 days.

 

Kevin

[Recuva deep scan takes days]

Thanks for your help and feedback, Augeas.

 

Can you check how much memory is in use, and how much of other resources it's using?

 

My Windows 7 performance monitor shows 2.09 GB steadily in use. I don't use CleanMem, but from the looks of the stats below, the process is I/O bound and not memory or CPU bound.

 

Physical Memory (MB)

Total: 3758

Cached: 1044

Available: 1608

Free: 615

 

CPU Usage varies between 0% and 3%.

 

recuva64.exe shows the following memory usage:

 

Hard Faults/sec: 0

Commit (KB): 239,640

Working Set (KB): 249,104

Shareable (KB): 14,140

Private (KB): 234,964

 

and the following CPU usage:

 

Threads: 11

CPU: 0

Average CPU: 0.00

 

and the following Disk I/O:

 

Read (B/sec): 33,317

Write (B/sec): 0

Total (B/sec): 33,317

I/O Priority: Normal

Response Time: 671

 

Kevin

 

P.S. Estimated time left is currently: 17 days

[Recuva deep scan takes days]

Now:

Estimated time left: 2 days

 

I'll try to keep up my ongoing report over the next days (and weeks, if necessary).

 

Kevin

[Recuva deep scan takes days]

Day 5 of uninterrupted running of Recuva as described initially, and I report the following information from the "Scan" dialog:

 

Stage 1 of 3: Scanning drive for deleted files

Current progress: 0%, 175848 files(s) found

Estimated time left: 1 day

 

Thanks,

Kevin

[Recuva deep scan takes days]

Then 24 days, and now 25 days...

[Recuva deep scan takes days]

In the hours since the previous post, the Estimated time left jumped from 46 days to: 1, 2, 6 and then (currently) 17 days.

 

Still running...

 

Kevin

[Recuva deep scan takes days]

In postings written previously by other users, the deep scan option has been reported sometimes to take days to complete on large drives:

 

11 days:

http://forum.pirifor...showtopic=36182

4 days:

http://forum.pirifor...showtopic=31361

 

I hope to make an ongoing report in this thread on the recovery of a 1TB external hard drive connected via USB2.0 using Recuva v1.48.982 (64-bit).

 

The computer is running Windows 7 Professional (64-bit) on a separate, SSD hard drive. It has 4 GB RAM and an Intel Core i3 CPU M 330 @ 2.13 Ghz.

 

I've chosen deep scan and scan for non-deleted files because without these options, I was not able to recover the files I know were on the drive.

 

I began my scan on 2013-10-13, 4 days ago.

 

The Recuva "Scan" dialog currently says:

 

Stage 1 of 3: Scanning drive for deleted files

Current progress: 0%, 175848 file(s) found

Estimated time left: 46 days

 

The light is blinking on the drive being scanned as if it is running and busy, and every half hour or so the "Estimated time left" will change. It has had values such as 24 days, 34 days, 39 days, 44 days, and 41 days, not necessarily in that order.

 

Kevin