jahtrust

Sry for the confusion. I was talking about memory in terms of RAM and not disk space. Recuva fills up the 96 GB and then terminates. As @Nergal said the scan got all file types regardless of any filter and the selection was to be made subsequently to the scan according the desired file type to be recovered - so the attempted recovery(!) probably considered a fraction of the 48 million files. On the other hand, the scan did produce 48 m files at 10% of the estimated scan time already which led to exceeded RAM - so I wonder if I am the only one having this issue since there are far greater disk volumes requiring recovery I imagine Anyways - thanks for the help guys and also for maintaining this community!

I see. Yet as I understood it these were 48 million total files (before I applied the filter), not pic files and I specifically tried to recover only pics which I thought were less. Anyway, meanwhile I tried to recover just a selection of the images but a) they were all "unrecoverable" which I suppose is due to cancelling the search and images not being put together/being readable yet, and b ) there were thousands of images found with the same file name and hence not many individual images were found in general (also because I had to cancel the search at 10% before RAM was full and the workstation froze and restarted). I can`t really assess what you meant by that. Does Recuva read "everything" into memory or does it write "everything" to disk? The latter makes sense of course as for the recovery - yet I wonder what`s being stored/read into RAM which hardly can be the data itself, can it? Anyhow - as far as I can see this renders recovery using Recuva impossible for me. Thanks for your help @all - appreciate it

Alright - thank you

Thank you for the quick reply! Indeed I did try to restore all found .jpeg files - I wasn`t expecting the total size to be so large since the original folder had "only" about 50 GB. Could you please shed some light on how so many copies of the images can be found and also what exacty is being stored in memory? Regarding the only option I seem to have (namely cancelling the search after 10% before RAM is filled - which probably will only get me a fraction of the data!?): is Recuva the right choice, i.e. is there a way to work around the memory issue or do I need to look for alternatives? I really appreciate your help @Nergal!

*update* Seriously? Cancelling after 10 % of the estimated scan time and only recovering .jpeg files the estimated disk space for the recovered data is 30x larger than what the original drive capacity was??? And the initial folder containing the images only had about 50 GB... What is this?

Hy there and thank you all for your effort with Recuva! I fiddled with drive names and of course ended up in formatting the wrong drive. To top it up it was a drive with some corrupted sectors, so I cloned the drive (1 TB) onto another 1 TB drive in order to recover my data. The issue is, that when I start a deep scan (there are 3 small new files written on the formatted disk - so only they pop up if I do a normal scan) it writes about 100 GB of data into RAM and terminates with an error translating to "The instruction/statement in "0x00 ..." referred to memory at "0x00 ...". The operation could not be performed in memory" (screenshot attached). Manually cancelling the scan before RAM is full (16% of estimated scan time) results in the same thing since processing seems to use RAM, too!? I read that years ago people had issues with 4-6 GB of RAM - yet 96 GB? I must admit that there are plenty of files on the drive (some numerical modelling results - i.e. approx. 50 million files after 10% of the scan). Now I wouldn`t mind ditching most of the results since they are backed up - but there are some thousand images, too, which I need to restore, preferably with intact file names. What could be the reason for this RAM issue and how can it be solved? Help is highly appreciated!!