Recovery of Acronis true image backup/archive files. (tib)

[Alt]

Mainly I think my problem is that I'm not sure how to calculate the offset accurately or I'm misunderstanding what I'm doing wrong. What is a good resource to reference that explains what the offset is and how it is calculated. I'm sure some of the non-power users could benefit from having that information in hand.

I think, this article should help: http://www.r-tt.com/Articles/Creating_C ... ndex.shtml.

[Sn3akyP3t3]

That's an excellent tut for the offset value! Exactly what I need. However, it doesn't reference the built in editor to create <?xml version="2.0" user created known file types. How do I take what is known from the tut you linked to create a known file type using the editor? I apologize as I probably should be referring to the manual in the new version I just installed recently to find it, but I feel this is a key point that I didn't grasp almost a year ago when I used it then.

[Alt]

How do I take what is known from the tut you linked to create a known file type using the editor?

I think you may learn how to find the required data from the tut, and create the xml 2.0 file type description using the graphic editor. See the R-Studio online help Customizing File Types.

[Sn3akyP3t3]

I'm using 2.1 build 476.

I created a known file type using the editor and resulted in this XML:
<?xml version="1.0" encoding="UTF-8"?>
<FileTypeList version="2.0">
<FileType id="747" group="Archive" description="Acronis True Image" features="" extension="tib">
<Begin combine="AND">
<Signature>\xb4nhD</Signature>
</Begin>
<End combine="AND">
<Signature offset="3">\xb41\x96\x17</Signature>
</End>
</FileType>
</FileTypeList>
I tested it against my 1.5 GB known good .tib file on a 4GB USB key and it was able to be recovered. I verified with a MD5 checksum that they were identical. I then scanned the troubled drive and resulted in no found .tib files.

I decided to try again the old XML which is this:
<?xml version="1.0" encoding="UTF-8"?>
<FileTypeList>
<FileType id="747" group="User Custom" description="Acronis True Image" extension="tib">
<Signature from="begin" offset="0">\xB4\x6E\x68\x44</Signature>
<Signature from="end" offset="3">\xB41\x96\x17</Signature>
</FileType>
</FileTypeList>
Which resulted in found .tib files in the Extra Found Files section and probably elsewhere, but haven't walked all found partitions in the device view. I haven't confirmed whether or not the found .tib files are corrupt or valid. That I haven't yet determined. The files are quite large and will take some time to recover and examine.

I'll post back when I have results from files analyzed after recovery. As of right now my concern is the observation of no .tib files found using the first posted XML. Does my syntax look good or is something not kosher or is this a bug?

I didn't think of it until now, but I should have run another test using the old XML against my USB key. I'll do that as well and post the results. I'm getting ahead of myself being hopeful for successful recovery

[Sn3akyP3t3]

Both the old xml and new recover the test environment USB with known good .tib file and the checksum comparison of them is exact. I'm still unsure why the new xml doesn't perform the same way as the old during actual recovery. For now, I'm using the old one and have recovered over 500GB of potential .tib data with 400GB of potential recovery data still being recovered as I type. Once I have them all on my 2TB disk I'll bring them over to a windows machine with Acronis loaded so I can start attempting to access the data. I expect many of the files to be corrupt, bogus, or part of some incremental cycle. I'm praying i find an intact full backup file in there somewhere among the duds.

The only problem I'm having now is that when Acronis version 8 was set up it was doing incremental backups I believe with some rule to create a new full backup every x cycles or something to that extent. I don't think Acronis intelligently looks into the files to identify which ones should be paired. The logic I believe is weakly integrated into the file name itself which can be modified by a user and/or during recovery. Unless I'm wrong, this is not very smart because no application should trust user input and thats exactly what can happen here to cause a major failure of the product! I'll post back if anything I have is recoverable, or worst case... not, or I find anything more about the logic between incremental backup files. Here is some advice on user input and application development from OWASP: https://www.owasp.org/index.php/Don%27t ... user_input

[Alt]

Can you send me both the xml files as they are, I'd look through it?
raptorbck (at) gmail (dot) com.

[Sn3akyP3t3]

Yes of course, sending now. Sorry for the delay in response. I've been disheartened by failure and haven't been able to scrape together ample time to figure out how to approach this problem for best chance of success.

[Guest]

I cannot see the .tib files in R-Studio version 7.0.154111 (for Windows) as Known File Types. Will they be added in a future release? Or do I need to create the file?

[Alt]

Will they be added in a future release? Or do I need to create the file?

There're some considerations that should be kept in mind. f Acronis true image backup/archive files are large. Or, more accurately, huge. Such files are quite often fragmented. R-Studio cannot recover fragmented files using scan for known file types. So, there may be a lot of false positives. So, I don't know.

[Alt]

Yes of course, sending now.

I received them, and will look through the problem ASAP.