Jump to content
CCleaner Community Forums

Kevn

Experienced Members
  • Content count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Kevn

  • Rank
    Member
  1. Recuva deep scan takes days

    Thanks Alan_B and Augeas. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Recuva deep scan takes days

    Thanks for your help and feedback, Augeas. 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
  8. 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
  9. 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
  10. Recuva deep scan takes days

    Then 24 days, and now 25 days...
  11. 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
  12. 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
×