Jump to content
Piriform Community Forums
Kevn

Recuva deep scan takes days

Recommended Posts

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:

4 days:

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Two points

First, of course it takes a while, think about what it's doing.

Second the time you see is an estimate - based on the speed and size of your harddrive, your cpu and your RAM. The time will expand and contract as the procedure continues. A deep scan is not something one sits and watches and will often take a day or even perhaps longer; this is truth for any disc recovery programs.

Share this post


Link to post
Share on other sites

 

11 days:

4 days:

 

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).

Sorry, but I think you may be comparing Apples and Peanuts.

 

Reading data from an external USB2 drive takes far longer than from an internal SATA connected drive.

 

Zentimo xStorage Manager shows me that reading 3 MB files and 100 MB files is done at the same speed for each of my USB2 Flash Drives,

and the actual speed of each was between 25 MB/Sec for the best and 13 MB/Sec for the slowest,

but each and every one could only read 32 KB files at a speed between 4.12 MB/Sec and 5.3 MB/Sec,

apart from a USB3 Flash in my USB2 port that read 32 KB at 6 MB/Sec.

 

I conclude that if Recuva attempts to read 4 kB clusters via USB2 then it will be restricted to far worse than 4 MB/Sec.

 

Sometimes a USB2 drive only runs at USB1 speed, which is another world of pain.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Now:

Estimated time left: 2 days

 

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

 

Kevin

Share this post


Link to post
Share on other sites

I've just deep scanned a 250 gb usb2 attached NTFS drive, 150,000+ files, in just under an hour (on an ancient Dell 32-bit P4 desktop). It's perhaps simplistic to say that scanning a 1 tb drive should take four times as long, i.e. four hours, but surely it shouldn't take this long.

 

I'm wondering if there is a scarcity of memory? Recuva gathers and sorts its results in memory, and although it's only showing 175k files there may be far more than this amount being stored. Can you check how much memory is in use, and how much of other resources it's using?

 

Do you use CleanMem? Worth a try. Asuming that Recuva is on the deep scan phase then it should be reading sectors in sequence. Not too onerous, except that there's a lot of them (two thousand million by my calculator). I can't think of much else that's feasible.

 

PS When you reach stage 2 you can chop the scan if you wish. All you've found will be displayed and I've never seen any need for stage 2 and 3 - perhaps someone can enlighten me.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
I've just deep scanned a 250 gb usb2 attached NTFS drive, 150,000+ files, in just under an hour (on an ancient Dell 32-bit P4 desktop). It's perhaps simplistic to say that scanning a 1 tb drive should take four times as long, i.e. four hours, but surely it shouldn't take this long.

Just to check (as this seems fast to me) did you fully recreate Kevn's settings (deep scan + non-deleted)

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.

EDIT: what, exactly, happened to your data that you feel you need both deep scan AND non-deleted? This seems a silly combination to me, either your files are deleted or they aren't. A deep scan is useful if the files in question were long ago deleted or slightly overwritten. A non-deleted scan will only be of use if the drive was reformatted, because, those files were not overwritten and never recieved a deleted MFT tag.

I can really think of no reason you are going to find something on this scan that you didn't find on two separate scans (one deep scan and one non-deleted scan)

 

EDIT2: a non-deleted will also present you with every file from every previous formatting which was not deleted or overwritten. How many live (non-deleted reachable via windows explorer) files are currently on the drive? How full was it before the data loss. Again please help us by providing the method of data loss.

Share this post


Link to post
Share on other sites

Augeas tested performance on a NTFS drive

 

Should Kevn expect a slower speed if his drive was FAT32 ?

Share this post


Link to post
Share on other sites
Augeas tested performance on a NTFS drive

 

Should Kevn expect a slower speed if his drive was FAT32 ?

Alan where are you getting that kevn's drive is fat32? I don't see that information anywhere, and considering the size of the drive, I doubt that it would be FAT32.

Share this post


Link to post
Share on other sites

Kevin never said what his format was so I raised the "if" possibility.

 

It may be worth considering whether backward compatibility exists between USB2 and USB3 when dealing with an HDD.

 

Zentimo Speed tests on a USB2 Flash drive show a slight improvement when "mismatched" with USB3 Port :-

 

Connected to Addon Extra PCI Express USB3 Port :-

USB DISK 2.0 USB Device
MULTIBOOT (F:), 7.4 GB "FAT32"
Type of file			Speed of reading		Speed of writing
Small files (32.0 KB):		5.72 MB/s			1.13 MB/s
Medium files (3.0 MB):		27.73 MB/s			6.41 MB/s
Large files (100.0 MB):		29.24 MB/s			7.63 MB/s

Connected to Built-in Basic USB2 Port :-

USB DISK 2.0 USB Device
MULTIBOOT (F:), 7.4 GB "FAT32"
Type of file			Speed of reading		Speed of writing
Small files (32.0 KB):		4.54 MB/s			1.03 MB/s
Medium files (3.0 MB):		23.94 MB/s			6.16 MB/s
Large files (100.0 MB):		25.17 MB/s			7.40 MB/s

 

Zentimo Speed tests on a USB3 HDD show it is SLOWER than Flash when reading on a mismatched USB2 Port

and unbelievably very much slower than a Flash drive when "mismatched" on a USB2 Port :-

 

 

Toshiba 1 TB USB3 HDD
N.B.
Partition J:\ is at the fast start end of the drive
Partition K:\ is at the slow far end of the drive

Connected to Addon Extra PCI Express USB3 Port :-

TOSHIBA External USB 3.0 USB Device
TOSHIBA EXT (J:), 1000.0 MB "NTFS"
Type of file			Speed of reading		Speed of writing
Small files (32.0 KB):		18.72 MB/s			12.22 MB/s
Medium files (3.0 MB):		83.73 MB/s			65.27 MB/s
Large files (100.0 MB):		113.03 MB/s			113.48 MB/s
Tosh-Top-1GB (K:), 999.0 MB "NTFS"
Type of file			Speed of reading		Speed of writing
Small files (32.0 KB):		18.69 MB/s			11.79 MB/s
Medium files (3.0 MB):		48.10 MB/s			38.20 MB/s
Large files (100.0 MB):		51.76 MB/s			54.91 MB/s

Connected to Built-in Basic USB2 Port :-

TOSHIBA External USB 3.0 USB Device
TOSHIBA EXT (J:), 1000.0 MB "NTFS"
Type of file			Speed of reading		Speed of writing
Small files (32.0 KB):		8.01 MB/s			4.45 MB/s
Medium files (3.0 MB):		16.08 MB/s			625.90 KB/s
Large files (100.0 MB):		17.21 MB/s			695.12 KB/s
Tosh-Top-1GB (K:), 999.0 MB "NTFS"
Type of file			Speed of reading		Speed of writing
Small files (32.0 KB):		7.76 MB/s			4.14 MB/s
Medium files (3.0 MB):		18.10 MB/s			868.29 KB/s
Large files (100.0 MB):		19.49 MB/s			785.26 KB/s

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Yes, I did a scan for non-deleted files as well as a deep scan. My disk is OK and I assume Kevn's disk is also, as he hasn't mentioned any fault. The disk is a second-hand 2.5" job, I don't know it's history.

 

I don't know about we, but certainly I'm guessing what Recuva is doing. A scan of the MFT should be very fast, then scanning the rest of the 1 tb should be more or less calculable. at a read speed of 30 kb a sec this is.... 33.3 million secs, which is 555k minutes which is 9260 hours which is well, just over a year. Someone check my figures please.

 

PS Written before Kevn's post. So the disk, or the contents, are suspect. I didn't know that Recuva would read a RAW disk?

Share this post


Link to post
Share on other sites

"Restore MFT/boot sector"

I have never heard of that, and Google ain't telling me :(

 

May I assume you were repairing the MBR and not the MFT ?

 

If a recent Windows 8 machine using UEFI has a GPT style HDD then adding an MBR would probably add to its woes.

 

I too am puzzled that Recuva accesses a RAW disk.

If Windows does not recognise a partition as having NTFS or FAT32 format then it calls it RAW and refuses to allocate a Drive Letter to it,

and Recuva 1.48 only scans partitions with drive letters.

 

Perhaps the HDD is mostly RAW but with a tiny partition that has a drive letter,

and Windows Explorer and Recuva are dealing with that tiny partition,

but are being deceived by corrupt MFT of FAT tables that recursively cross-link from the end to the beginning.

Give me 5 minutes and I can have another half dozen guesses :P

 

I suggest a screen-shot of Windows Disk Management showing all the Volume and Disk information,

and also please state the Drive Letter that Recuva is trying to scan.

Share this post


Link to post
Share on other sites

Speak to us Kevin. Twelve hours of posts, twelve hours of silence.

 

It's a pity we had to wait until post 16 to discover the state of the disk. It was slow from new, suffered a power outage, was unbootable, had a boot sector restore, and is a RAW partition. I'm surprised Recuva gets anywhere near it.

 

It would be nice to have some sort of resolution.

Share this post


Link to post
Share on other sites

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

post-67687-0-12492700-1382278517_thumb.png

Share this post


Link to post
Share on other sites

Currently back to the state before the restart:

 

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

Estimated time left: 12 days

 

Thanks,

Kevin

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I was surprised to see this HDD has 3 recovery partitions,

and astounded by the "EFI System Partition".

 

Was this a GPT style formatted HDD ?

 

Is it possible to change the drive letter of the RAW partition ?

 

Has this HDD been used with any sort of Apple computer ?

I ask because I have read

As you can see, the partition is protected in such a way that even the powerful Disk Management tool cannot do anything to it. Note that it's not because the partition is EFI, it's because the tool that created that partition had marked it in a way that prohibits other tools to tamper with it. (That's usually the case for the system hard disks formatted on the Mac computers.)

https://www.winabili...disk-partition/

 

It occurs to me that when partition G:\ was either NTFS or FAT32,

then either EFI or Apple could prevent other tools from changing partitions on this HDD,

and might even prevent Windows from changing partition G: drive letter,

hence when the file system was changed perhaps the drive letter remained frozen at G:\ and could not be removed in the way that Windows would have wished.

 

It may be worth downloading a freeware ISO and burning a bootable Recovery CD for a Linux very of the HDD,

http://www.partition...m/download.html

 

N.B. My experience in the past was that this cannot change or even recognise drive letters because it was based on Linux,

but at least it will give you a different perspective.

 

Recuva depends on Windows and the assigned drive letter and Windows is obviously NOT working as it should.

It is predictable that Windows will not allow a drive letter to be allocated to a RAW partition,

and the fact that your Windows is NOT being predictable in its handling of your HDD suggests that when Recuva Searches G:\,

Windows could be feeding it data from any location on the drive.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×