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?
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?
looking at your screenshot tells me you're trying to blindly restore all found without looking at the results. Each file listed there have multiple copies. What you are doing, restoring files, cannot be done without forethought. You will be more successful in looking. Also recuva still scans for everything even if you apply a filter, it's best to put the filter on after the scan has occured.
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 <a contenteditable="false" data-ipshover="" data-ipshover-target="<___base_url___>/profile/21882-nergal/?do=hovercard" data-mentionid="21882" href="<___base_url___>/profile/21882-nergal/" rel="">@Nergal</a>!
It doesn't matter what the original folder size was, you are finding, and attempting to recover, all deleted pic files. Recuva has found 48 million pic files, even at 1 cluster each that's nearly 200 gb. At ten clusters each, say, that's 2 tb to recover. By the way I have no idea what Recuva writes to memory, apart from everything.
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).
7 hours ago, Augeas said:
<div class="ipsQuote_contents">
<p>
By the way I have no idea what Recuva writes to memory, apart from everything.
</p>
</div>
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.
That's me trying to be too clever. When Recuva scans it holds all its info in memory as it doesn't write to the disk, for obvious reasons. When it runs a recovery I can't see a reason why much more is held in memory - a recovery log I suppose, which can be quite large with 48 million files to be recovered.
But your original post says that you're running out of ram, and your second post says you're running out of disk space.
Post two also says on the bottom line that 48 million files are being recovered after the pic filter has been applied. You are biting off a great deal, perhaps more than Recuva can chew.
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!