Why does Recuve simply ignore some files?

Recuva
1

Hey all! I am new here. This is a really nice forum, I love the green theme.

I just installed Recuva 1.40.525, hoping to be able to recover a backup file that just got deleted by Acronis TrueImage by mistake. It's a long story. But I know the file name, I know the file size and I know where it was stored.

File: MyBackup__2009-12-31.tib

Size: 533 MB

Location: D:\MyBackups\

Note that this is not my system volume. This volume is merely used, so there are virtually no write operations done on it that would ruin my chances of recovering the file.

Recuva successfully found 9 of the 10 or 11 lost files, depending on how you count. Let me clarify that a little bit. From the beginning there were 10 backup files with the TIB file extension. That was before TrueImage decided to merge (consolidate) these into one single file, and it did this in complete radio silence, without my consent and without a single notice. Like I said, it's a big story, and Acronis has been notified about it. But the main thing is that there were 10 files from the beginning, these were merged into 1 file, then this 1 file got deleted by mistake from within TrueImage.

Now Recuva is listing 9 files, but it ignores 2 files. Can someone explain to me my why it ignores the 2 files? Can I tell it to show me those 2 files somehow?

I would like to get back to the point where I had the 10 individual files. That would be best. This is because the consolidated file appeared to contain errors. But I would be happy if I could at least get back the 1 consolidated backup file, at least.

Can someone help me with this?

Thanks!

2

Recuva, in normal scan, will list all the deleted entries in the Master File Table. It won't ignore two entries, it's just that they aren't there any more. It's likely that the two entries in the MFT that used to hold details of these files have been used by some other files, possibly temps or logs etc. created by the Acronis application, of which I know nothing. The consolidated file, being a very recently created file, is likely to be overwritten first. The other file is just unlucky.

You might find the files with a deep scan, but there's no guarantee.

3

Thanks for replying!

By normal scan you mean quick scan, right?

I did a deep scan, not a quick scan. So the 2 files I saw withing parenthesis labeled as "ignored" on the status bar, those were only fragments of 2 files that could no longer be recovered?

Well, I am not so sure anymore that the 533 MB file, you know the "consolidated" file, that it was actually a consolidated file. Here is why.

Assume that you have 10 files with the following file sizes.

File 1: 100 MB
File 2: 150 MB
File 3: 200 MB
File 4: 250 MB
File 5: 300 MB
File 6: 350 MB
File 7: 400 MB
File 8: 450 MB
File 9: 500 MB
File 10: 550 MB

We are assuming that they are numbered according to the time they were created, so number 1 would be the oldest and number 10 would be the newest. This will give a total of 3250 MB. If they are merged or "consolidated" in backup software terms, it means that one of them would become preciesly 3250 MB in size.

Which one would become 3250 MB? It's usually the first file that is consolidated. The first backup is usually a full backup, and all new backup files thereafter are incremental backups containing only the changes done since the last full lbackup. This is the same for most backup software. But we will assume that file number 10 is the consolidated one, so file 10 is now 3250 MB.

By increasing the size of file 10 from 550 MB to 3250 MB while at the same time deleting the first 9 files, that would cause the clusters of those 9 files to be overwritten by the new bigger file. The chances for this happening is especially big when the overall free disk space is limited.

What I'm saying is that by consolidating the backup files to one single file in this type of scenario would greatly decrease the chances of restoring the files that get deleted by this process.

Now, if the files are consolidated into one single 3250 MB file, by reverting back the consolidation process so that you have 10 individual files again, the total of the 10 files should not exceed 3250 MB.

File 10 = 3250

File 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 3250 MB

The sum of the individual file sizes cannot exceed 3250 MB. If individual files are bigger than the one consolidated file, then that backup most probably never was consolidated at all.

In my situation the last file was 533 MB after the first nine files disappeared. They disappeared for some reason when I attempted adding that last file to the list of backups in Acronis True Image 2011. Since they did disappear from the holding folder, I only assumed they were consolidated by Acronis True Image 2011. I thought it needed to consolidate them first, before adding the backup to the list of backups.

But for this to hold true, when reverting back the process and "unconsolidating" or restoring back the removed files, the individual files cannot be larger than the consolidated single file.

Well this is what I discovered when I restored the 9 files. For instance, one of the files was 1,22 GB. But the last file was only 533 MB. This means that the last file was not at all a consolidation of all the previous files, because a 533 MB file cannot hold a 1,22 GB file, plus additional 8 files with just about the same big size.

These are the files I restored with Recuva.

MyBackup__2009-12-18.tib   882 MB (925?325?824 byte)
MyBackup__2009-12-20.tib   1,46 GB (1?573?391?872 byte)
MyBackup__2009-12-21.tib   1,22 GB (1?320?400?896 byte)
MyBackup__2009-12-23.tib   1,56 GB (1?683?230?208 byte)
MyBackup__2009-12-25.tib   1,41 GB (1?516?966?400 byte)
MyBackup__2009-12-27.tib   229 MB (240?476?160 byte)
MyBackup__2009-12-28.tib   323 MB (339?008?512 byte)
MyBackup__2009-12-30.tib   168 MB (176?160?768 byte)
MyBackup__2009-12-31.tib   533 MB (559?581?184 byte)

These are the files I restored with TuneUp Utilities 2011 (10.0.4310.27).

MyBackup__2009-12-18.tib   882 MB (925?325?824 byte)
MyBackup__2009-12-20.tib   1,46 GB (1?573?391?872 byte)
MyBackup__2009-12-21.tib   1,22 GB (1?320?400?896 byte)
MyBackup__2009-12-23.tib   1,56 GB (1?683?230?208 byte)
MyBackup__2009-12-25.tib   1,41 GB (1?516?966?400 byte)
MyBackup__2009-12-27.tib   229 MB (240?476?160 byte)
MyBackup__2009-12-28.tib   323 MB (339?008?512 byte)
MyBackup__2009-12-30.tib   168 MB (176?160?768 byte)
MyBackup__2009-12-31.tib   533 MB (559?581?184 byte)

These are the files I restored with Get Data Back for NTFS (4.22).

MyBackup__2009-12-17.tib    0 byte
MyBackup__2009-12-18.tib    882 MB (925?325?824 byte)
MyBackup__2009-12-20.tib    1,46 GB (1?573?391?872 byte)
MyBackup__2009-12-21.tib    1,22 GB (1?320?400?896 byte)
MyBackup__2009-12-23.tib    1,56 GB (1?683?230?208 byte)
MyBackup__2009-12-25.tib    1,41 GB (1?516?966?400 byte)
MyBackup__2009-12-27.tib    229 MB (240?476?160 byte)
MyBackup__2009-12-28.tib    323 MB (339?008?512 byte)
MyBackup__2009-12-30.tib    168 MB (176?160?768 byte)
MyBackup__2009-12-31.tib    533 MB (559?581?184 byte)

These are the files I restored with Norton Utilities (15.0.0.122).

Deleted ZIP Archive 1.zip   228 kB (233?512 byte)
Deleted ZIP Archive 2.zip   208 kB (213?264 byte)
Deleted ZIP Archive 3.zip   136 kB (139?962 byte)
Deleted ZIP Archive 4.zip   158 kB (162?754 byte)
Deleted ZIP Archive 5.zip   109 kB (112?638 byte)
Deleted ZIP Archive 6.zip   454 kB (465?228 byte)
Deleted ZIP Archive 7.zip   523 kB (536?487 byte)
Deleted ZIP Archive 8.zip   13,9 kB (14?286 byte)
Deleted ZIP Archive 9.zip   117 kB (120?595 byte)
Deleted ZIP Archive 10.zip  62,1 kB (63?684 byte)
Deleted ZIP Archive 11.zip  24,9 kB (25?518 byte)
MyBackup__2009-12-17.tib    0 byte
MyBackup__2009-12-18.tib    882 MB (925?325?824 byte)
MyBackup__2009-12-20.tib    1,46 GB (1?573?391?872 byte)
MyBackup__2009-12-21.tib    1,22 GB (1?320?400?896 byte)
MyBackup__2009-12-23.tib    1,56 GB (1?683?230?208 byte)
MyBackup__2009-12-25.tib    1,41 GB (1?516?966?400 byte)
MyBackup__2009-12-27.tib    229 MB (240?476?160 byte)
MyBackup__2009-12-28.tib    323 MB (339?008?512 byte)
MyBackup__2009-12-30.tib    168 MB (176?160?768 byte)
MyBackup__2009-12-31.tib    533 MB (559?581?184 byte)

The 9 files that are common to all four applications are binary same. I have let Byond Compare 3 do a CRC check on them. But Norton Utilities didn't restore the last modified dates, instead it set new dates for the restored files. It's not a big deal but it may be useful to know the modified date of the original file in some scenarios. Also, the TuneUp Utilities did restore the original dates, but the time stamps were differing by about 2 hours, more or less. Recuva didn't have this issue.

But isn't it possible to restore 0 byte files with Recuva? As you can see I have tried out some other recovery software as well and some of them have found a 0 byte file. One such software is Get Data Back for NTFS. There may be scenarios where you would want to recover 0 byte files as well, in case you need the file name. Even thou the file may not contain any secrets, the file name itself may be too informative, revealing confidential information, and you want to shred it just to make sure it is safely deleted.

It might just be that this 0 byte file is one of the 2 ignored files during deep scan with Recuva.

The 11 ZIP files found by Norton were some kind of deleted files with very consistent file name schemes like "Deleted ZIP Archive 1.zip" up to Archive 11. They may be some kind of ZIP versions of the backup (TIB) files. Or so I thought. They are 1,99 MB (2?087?928 byte) in total, so they are pretty much useless and not needed anyway, given the fact that the real backup files are over 300 MB each. Also, Norton Utilities prompted "Repair File?" when recovering these ZIP files. "'Deleted ZIP Archive 1.zip' has been recovered and has been detected as corrupt. Would you like to repair this file?" Later on after the recovery process of all files it tells that some files may not have been repaired.

After all the investigation I was unable to recover this backup, neither with Acronis True Image 2011 nor with True Image 2010 with wich the backup was created. I think it has to do with that 0 byte file. I think that first file should be at least few hundreds of MB in size for this backup to be complete. Although, this was not a critical backup for me. I was only trying to recover some old software and log files. I can do without those logs, and I can reinstall the software.

However, I am really impressed with Recuva! I am impressed that Recuva was just about as effective as these other recovery software tools. It means that Recuva does for free what others want you to pay for. And even if you do pay for it, there's no guarantee that they will be more successful than free tools like Recuva.

4

The tale of ParetoLogic Data Recovery Pro

I remember once using ParetoLogic Data Recovery Pro to try and locate a file with a specified file name on a busy C system volume. It was able to find the exact file I was looking for, even though none of the other six or seven tools I had tried with did not. It seemed very impressive. But it took about three hours to complete the scan. And as it turned out that software is not free at all, it costs 50 USD. But there is no price listing on the website, at least it's not easy spotted. You only discover that it costs 50 USD after installing it and after running the scan and finding the file. And of course you need to pay for it first before you can use it to recover the file. Compare this to Norton Utilities trial edition which also costs 50 USD but it will actually restore the files for you, so you can inspect them and see if they are healthy, even though you don't have a full license yet.

And here's another twist to the story: the license is not perpetual! You don't just pay 50 USD for a single license and for a given version of the software and use it for as long as you want, just like most software products including Microsoft Windows and Office products. You have to actually pay 50 USD every year! That's their licensing policy they say. It's a bloody subscription license. You can think of it as Anti-Virus software license which are renewed every one to three years. But I understand the concept of Anti-Virus software licensing, since new viruses are created every day, you need the latest virus definitions to counter these threats. That's what you are subscribing to. But what are you subscribing to with ParetoLogic? Just the ability to use the damn software! You don't get any other benefits, I've checked. Why would I pay 50 USD annually just to use this software once or twice in a three year period? It's not like I intentionally screw up my files on a regular basis, just for the fun of it to see what happens, to see if I can restore them.

Regardless of how effective ParetoLogic Data Recovery Pro software is, I advice against buying a license. Correction: you don't buy anything, and you don't own anything, you just subscribe to it as if it was some kind of service and not a product. This is a greedy company who just wants fast earned money. I'm not too sure that they even found that file they said they did. They could just tell the software to show me that they have found the file I was looking for, just to get me in and start paying a 50 USD annual license fee. You can never know if it works, because you can not check and validate the files it supposedly founds, since it won't allow you to recover until you pay. You know, like those funny little web ads like "warning, your computer is at risk, click me and I will help you".

So far I have had the chance to use Recuva two or three times in a real situation. In this latest situation it has been most successful, it was just as good as the other competing commercial products. Why it was less successful in previous situations, I can't really tell. There are so many factors that count in. Like that time when I was using the ParetoLogic thing, the file I sat out to find was stored on the C system volume which is always busy writing information. The file might just got overwritten before I could recover it with Recuva. It's interesting in this context that the ParetoLogic thing was able to locate that file, while both Recuva and about five others failed. I think Recuva really is a project worth donating to. If it was a commercial product it would definitely be worth buying. But I will sure make a donation, you do a great job with this software.

5

Ah, so it's not that two files aren't being shown, but that they are shown with (Ignored) in the State column, or where? I've never seen or heard of this with Recuva.

I shall have to pass on all your Acronis musings. I mean pass on them, not pass them on.

Recuva won't recover a zero byte file, but you can access the file name and path. You seem to imply that you should recover zero byte files and then shred them for security. This is incorrect as the original deleted file will still exist unshredded.

6 

File 1: 100 MB
File 2: 150 MB
File 3: 200 MB
File 4: 250 MB
File 5: 300 MB
File 6: 350 MB
File 7: 400 MB
File 8: 450 MB
File 9: 500 MB
File 10: 550 MB

We are assuming that they are numbered according to the time they were created, so number 1 would be the oldest and number 10 would be the newest. This will give a total of 3250 MB. If they are merged or "consolidated" in backup software terms, it means that one of them would become preciesly 3250 MB in size.

If your statement is true then Acronis must be as "dumb as a bag of hammers".

Both Differential and Incremental files hold information upon exactly what new data has been written to which sectors.

They may also, for all I know, stipulate which sectors held data that has now been deleted,

but they cannot hold information upon the OLD data that is now deleted or over-written.

This is the start of my Macrium backups :-

14/04/2011  23:06     6,223,702,084 D4F3BDD38CC36FC5-00-00.mrimg
16/04/2011  12:30       737,028,903 D4F3BDD38CC36FC5-01-01.inc_00.mrimg
16/04/2011  21:45       103,918,637 D4F3BDD38CC36FC5-02-02.inc_00.mrimg
17/04/2011  21:46       124,457,649 D4F3BDD38CC36FC5-03-03.inc_00.mrimg
18/04/2011  21:49       362,236,495 D4F3BDD38CC36FC5-04-04.inc_00.mrimg
19/04/2011  21:18        96,567,852 D4F3BDD38CC36FC5-05-05.inc_00.mrimg
20/04/2011  21:15        80,219,859 D4F3BDD38CC36FC5-06-06.inc_00.mrimg
22/04/2011  21:44       346,341,633 D4F3BDD38CC36FC5-07-07.inc_00.mrimg
23/04/2011  21:46        92,934,986 D4F3BDD38CC36FC5-08-08.inc_00.mrimg
23/04/2011  21:50       848,014,078 D4F3BDD38CC36FC5-09-09.DIF_09_x_.mrimg

The first 6 GB was the FULL image followed by a lot of changes in 2 days then the first Incremental.

Then 6 more incrementals and finally a differential with the total differences from the FULL.

If all the new data was only written to totally unused space the Differential would have reached

737,028,903 + 103,918,637 + 124,457,649 + 362,236,495 + 96,567,852 + 80,219,859 + 346,341,633 + 92,934,986

which is obviously far more than 848,014,078

The same is true if new data was only written to second-hand "single previous owner" used space,

i.e. sectors that have never been populated more than once.

At least half of all incremental file space is successive over-writing of what has already been over-written,

and if there is the slightest intelligence in "consolidation" there should be no need to retain information upon data that is no longer needed,

therefore I would have expected that on average a Consolidation would be less than half the size of the incrementals between 16/04/2011 and 23/04/2011

This demonstrates that, as is well known, when files are written they tend to re-use what has recently been vacated.

Quite obviously Windows is always fidgeting about with itself as it decides what went wrong with its file placements yesterday and tries to do better today,

and I have never seen an incremental of less than 40 MB even when all I did was create an Incremental, shut-down, reboot, and new Incremental.

If C:\ has not been defragged for a long time and an image is made, followed by full C:\ Defrag, followed by new Incremental image,

the Incremental is typically 30% of the size of the Full image, even though no files are changed, only which sectors they occupy.