Recovering a full MyBackup tib file that was removed accidentally

Hello I am a noob to acronis,
I accidentally removed the full MyBackup Tib file yesterday in the morning. I would like to recover this file to see if a certain large folder of 80 gigs can be restored to evaluate missing files after a complete backup. When reviewing the directories after the deletion i notice that there was approximately thirty gigs of missing information on the current hard drive. If anyone can give me an insight as to what the following actions can be done to recover the remove MyBackUp Tib files on external USB hard drive. It would much appreciated to resolved this headache.

 

First - do NOT perform any defrag's for the moment.

Second - try not to install or delete any programs.

Third - don't alter the placement/size of the page file or hibernation file (if activated).

Did you delete the file and it is now living in the rubbish bin or did you really delete the file from the disk?

If the second option you'll need to hunt down software that'll undelete files. If you already have a disk editing program or undelete software then these will restore your file.

If your disk is formatted as FAT32 then in the disk editing program find the FAT table and locate your file which will have the following entry ~yBackupTib, manually replace the ~ with an M the file will be back for your use, minus any parts that have already been overwritten. With an NTFS partition you will need to use undelete software as NTFS marks files as deleted in a different way.

Unfortunately Acronis Disk Director won't be of any help in this regard.

 

Note that if any part of the file is unretrievable, then the entire file will be useless, even if you can recover all but one bit of one byte.

 

Note that if any part of the file is unretrievable, then the entire file will be useless, even if you can recover all but one bit of one byte.

Thank you for that information TX for the help

 

I have a corrupt image which cannot validate and cannot be restored.
It can however be mounted, AND ALL FILES AND FOLDERS CAN BE COPIED.

This is a very special corruption.
I created a FULL image and then 3 differential images 2.tib, 3.tib. and 4.tib, all of which validated perfectly.
I then renamed 3.tib as 3.not, and could still validate both FULL and 2.tib., but 4.tib was rejected as not being part of the series.
There was however no problem mounting 4.tib and copying all the total system state as at that point in time, i.e. the contents of FULL plus 4

I would say that in general if a *.tib has been over-written or corrupted, it is ALMOST useless. Certainly it cannot possibly restore a bootable image.

But you still may be able to mount it, and you may be able to explore and copy a vital document.
It is JUST POSSIBLE that a corrupted *.tib could make the difference between have to completely retype a document and retrieving a document and then carefully reading and possibly editing to correct corruption.

F.Y.I. The purpose of my investigation was to see if Differential images were more resilient than Incremental.
If an Incremental image is corrupt, it is not possible to restore subsequent incrementals.
Unfortunately Differentials are just as vulnerable :-
If 3.tib is corrupt, none of them validate ;
If 3.tib is deleted or renamed, then FULL and 2.tib are O.K. but 4.tib is not part of the family
If 4.tib is renamed as 3.tib, it is part of the family but declared corrupt, probably because its creation name is embedded in the file and fails validation when compared with its current name.

MY RESULT :- I added a pre-image user task to move any existing Differential TIB to an indexed sub-folder before creating a new DIFF, so that each and every DIFF is called 2.tib, and the latest one co-exists with the FULL tib in the parent folder. I can instantly restore the latest DIFF, and any other DIFF just needs a quick move between parent and sub-folders. If any DIFF should ever get damaged, it now has no effect upon the viability of any of the others.

 

Alan,
TI was somewhat strange in its handling of differentials from the time they were first introduced. TI would not validate a differential image unless all of the intermediate ones are present. When they introduced Backup Locations it supposedly (I never use them) would do the validate without the intermediates if the archive was stored in an official backup location but Backup Locations were removed in TI2009 so I don't know what the status is.

Even though the archive with the missing differential would not validate the full and the last desired differential would restore properly which after all is the intent of a differential. The validation quirk is certainly not the right way to go about it.

 

The other terrible thing about validation is in combination with a task creating a FULL image.
If the task includes validation when the image is created, then T.I. V11 insists upon validating ALL the archives in the same folder.
I have suffered this with a Backup Location that already held 50 other FULL images. I assume it could happen with other folders that are not Backup Locations.

The task took 50 times longer than expected - end of computing for the day.
Not only was it a waste of time, it also showed each validate in the event log with NO CLUE upon which file was processed.
I fear that had any file failed validation :-
The log would NOT show which image was corrupt, and
The corruption of one image would probably abort the entire validation sequence, probably never getting to the latest image I really wanted to validate.

My task now creates WITHOUT validate and then I have to manually select the new image and launch validation.

I now view the task as a waste of time. The only benefit I now get is that it automatically creates a convenient file name based on date and time, instead of defaulting to a "MyBackup.tib" variant.

 

I have just downloaded a recovery program called RECUVA . It is free and the Slim version is less than 2MB. You can find it at recuva.com .
So far I have tested it on a pen drive and it can restore files that have not been overwritten. Similar results from an emptied recycle bin.

Now the crunch will be to see if it can find deleted .tib files. The program cannot see inside the Acronis secure zone but I remember I had deleted some .tibs from an USB drive that I have used in the past.
I have launched a deep scan but it still has 40 mins to run.
If I had been able to remember a particular file name for it to find the process may be a bit faster than an all deleted files search.

Will let you know if it can recover deleted .tibs as soon as the program has completed.

Xpilot

 

Mmm maybe .tib files are not in Recuva's vocabulary or perhaps files of very large sizes are not covered or I may have made the wrong selections in the first place. The end result was 49 deleted files found initally but when the run had completed there was zilch to restore.

I may play with it a bit more when I have time.

Xpilot

 

I lost a TIB over a year ago.

I tried many file recover programs.

Some were sold specifically to discover deleted media files (by which I mean music / photos / and other things that do not interest me.) I do not know how they achieve that focus, but could say that have a vocabulary that recognises such files.

I believe Recuva is in the more general purpose group of recovery programs.
and the chance of detection and recovery do not seem to be affected by file type.

Recuva was one of the minority that recovered most of the deleted TIB, but there was a break between two parts due to a disc write after the deletion.

I never used that partition after the accidental deletion until I thoroughly exhausted every possibility of recovery - and yet it was over-written.

I think the problem may have been that this deleted TIB was on an external drive in a "Backup Location" folder on a partition that I "quarantined" and never wrote to, but there was in that folder an acronis_backup_place.cfg which might have got updated whenever Acronis did anything to any archive elsewhere on the computer.

Regards
Alan