Finds the file but can't recover it

[Fractalogic]

I just accidently deleted a backup file. It's an Acronis True Image TIB file. Recuva 1.43.623 finds the file through the recovery wizard but it is unable to recover it. The "state" of the file is "unrecoverable". So the resulting file is 0 byte.

 

The file was stored at H:\My backup and the name of the file was File_backup_2012-10-18.tib.

 

Why does the recovery process fail? Is there no way to save it now?

 

I have stopped using the H disk because I know it can affect my chances of recovering the file. I really need this file.

[Augeas]

If it's more than 4 gb (or was, and I guess an image file could well be) then Windows erases the file cluster adresses on deletion. The data is still on disk but the entry in the MFT no longer points to it.

 

You can possibly find the file by running a deep scan: if the file is in extents then this will only find the first extent. If deep scan fails, or the file is in extents, then there's no practicable way of recovering the file - that I know.

[Alan_B]

If it's more than 4 gb (or was, and I guess an image file could well be) then Windows erases the file cluster addresses on deletion.

For future reference :-

Is it worth using the Imaging software option to split the backup into separate 4 GB files so that Recuva stands a chance of helping this type of situation ?

(I always thought the only reason was to facilitate subsequent backup copies to DVD)

 

Also, if the backup is saved to FAT32 then it is automatically split into 4 GB Files.

Is Recuva able to work on 4 GB FAT32 files regardless of File Cluster Size ?

[Augeas]

I think that Recuva has, in the last release or two, changed the way large files are reported. Previously, deleted files over 4 gb in size would be reported as zero bytes, and unrecoverable. Now it appears that the file size is reported, but with the comment that 'File's data could not be found on the disk.'

 

Although NTFS zaps both the file size and the cluster run info in the $Data attribute in the MFT record, the original file size is still available in the $File_Name attribute (although not necessarily accurate). Perhaps this is where Recuva finds the info.

 

If the file is under 4gb but in many extents then it may have forced the $Data attribute to become non-resident, i.e. to be held in a second MFT record for the file. In this case NTFS will, on deletion, zap the cluster run info in the MFT extension record, so the file is unrecoverable. It appears that Recuva also reports these files as 'File's data could not be found on the disk.'

[Alan_B]

Thanks

 

So Two backups is not enough, and Recuva is not a good substitute for a duplicate copy of a 46 GB image backup.

http://asdaqua.com/2012/10/02/tech-tip-2-backup-strategies/

[Augeas]

I don't really think that 'File's data could not be found on the disk' is very helpful. There's no explanation of what it means - standard Piriform action - and it certainly confused me. I thought that it meant, as in a human interpretation, that Recuva had looked at the disk and the clusters weren't there, as if the cluster numbers pointed off into space or something. It appears to be that the cluster addresses are invalid, i.e. they have been overwritten. Perhaps a better message would be just that, 'File's cluster addresses are invalid.'

[Super Fast]

Perhaps a better message would be just that, 'File's cluster addresses are invalid.'

 

To which a user will invariably probably ask, "Why can't you fix that?" LOL!

[Augeas]

It sounds like a perfect job for one of those mythical applications that reads data after one overwrite.