How to pause recovery

[Woutieke]

I've got a non responding external harddisk. Recuva is able to get most from it, it takes only very long to get the 1.5 Tb from the disk. How can I pause the recovery? Or might it be an idea to put a pause button in a next version of recuva?

[Alan_B]

Define PAUSE and why you want it.

 

Recuva should automatically resume after putting the PC into SLEEP mode and maybe HIBERNATE.

[Nergal]

Sadly this logically couldn't work as any use of the drive, but especially alan's sentence, can/will change the original results

[Augeas]

I think that the answer is that if you want to recover a large amount of data then you just have to accept that it will take some time. Or, try to recover in manageable chunks, which - if you have a list of many hundreds of thousands of files - isn't easy.

 

I've always thought that a pause function would be illogical, as the underlying data is subject to change at any time. But I've just run a test where I opened an instance of Recuva and scanned, then created and deleted a 2kb file, then scanned again and found, and recovered, the file.

 

I then ploughed through a few pages of the BBC's website, which used several hundred records from the MFT. I opened another instance of Recuva, and a scan showed no sign of my deleted file, as expected. However I could still recover the file in pristine condition from the first instance of Recuva. This indicates that Recuva holds the file's info in memory, and does not recheck when recovering. So a pause would be possible. Recover is after all a non-invasive procedure, if you recover rubbish there's no physical damage.

 

The OP might mean a pause and restart after a reboot or after some time, when the logic becomes more strained. Perhaps the possibility that a pause could last several days would make a pause function undesirable.

[Alan_B]

I opened another instance of Recuva, and a scan showed no sign of my deleted file, as expected. However I could still recover the file in pristine condition from the first instance of Recuva.

I am reasonably confident that the hash checksums of the original and recovered files would have been different.

 

I am certain that what you recovered had the exactly correct size and name and time stamps.

Is that what you mean by "Pristine condition".

That would happen because the first instance was using "Obsolete MFT Data" to determine how many bytes to copy and what name and time stamps to apply.

 

I have restored a Macrium Reflect "Intelligent" 10 GB Partition Image Backup of an HDD to both a 2 GB VHD and a 10 GB VHD.

 

Windows Explorer could see the exact same amount of files ( about 1 GB ) in the original HDD partition and both the VHD.

Recuva ( and other data recovery tools ) could see exactly the same amount of deleted files ( about 8 GB ) in the original HDD partition and both the VHD.

 

Because I used "Intelligent" backups the free space was NOT backed up,

but the live MFT was backed up and when restored to the VHD's it told them the original L.B.N.'s of files that were not available for restoration.

 

Recuva would have happily recovered 8 GB of empty sectors from the 10 GB VHD and then told me the original names and time stamps even though there was nothing there.

Recuva did recognize that most of the deleted files were outside the boundaries of the 2 GB VHD.

[Augeas]

The deleted file was a 2kb text file, so it used one cluster external to the MFT. When it was recovered it contained the same text. I assume (as we all do) that the info about this file, name, size, cluster number was collected by Recuva at scan time and stored in memory. Although the MFT record was subsequently overwritten, the cluster's lcn in memory (from the first scan) was used to retrieve the data - which hadn't been overwritten.

 

What's more interesting is that if you scan a cd with pics on it, look at them in Thumbnails mode, and then take the cd out of the drive, you can still recover the pics. I don't know if there's a size limits, I've recovered pics up to 650 kb. Other types of file have mixed results. I don't know why anyone would want to do this, but it amuses the geek in me.

 

On the other hand, if we put para 1 and 2 together, perhaps the text file in para 1 was retrieved from memory and not the disk. I suppose I should do another test this time watching the data cluster with WinHex or something.