Recuva deep scan takes days

Recuva
1

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

2

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

3

Then 24 days, and now 25 days...

4

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.

5

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.

6

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

7

Now:

Estimated time left: 2 days

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

Kevin

8

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.

9

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

10

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

11

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

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

13

Augeas tested performance on a NTFS drive

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

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

15

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

16

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

17

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?

18

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

19

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.

20

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