Corrupt TIBs, hex editing and the meaning of frustration
I am currently using Acronis True Image Home 2010 (build 6053) and have been using it faithfully for the last month or so. I had a daily full "Files and Folders" job which backed up selected folders only.
Unfortunately my system drive had a RAID failure, which required a system rebuild. When it came to recovery the content of my TIBs, I am unfortunate enough to receive "This is not the last volume in the archive".
File is not loadable via Acronis, or through Explorer. It cannot be read in the recovery wizard, or mounted (they're "Files and Folder" archives). No luck using bootable recovery either.
This is the case with ALL 30 of the backup archives, so this is not related to an individual file corruption.
The filename format follows the syntax : MyBackup__11_03_20101.tib
I'm assuming the trailing "1" on the filename is significant for some reason, as I also have confirmed valid achives that i created for test purposes that do not have this suffix.
The archives were specifically created as "Full", as I do not trust incremental backups. The data being backed up in this case is only 10-12GB in size, so this seemed appropriate. The backup target was another internal HDD, connected to the same SATA controller. The backup ran daily, successfully(?), for around 30 days.
Things I have already tried:
- setting full NTFS permissions, file ownership of the TIBs to the current user.
- Copying TIBs to several other volumes
- Creating a valid TIB as a full, with the same "files and folders" selection. I was hoping that if Acronis somehow believed my archives were incremental, I would be able to trick it when asked to select the last volume. No luck there.
- Browsing the TIB as a raw archive (using R-Studio), but no luck due to compression used.
I have also done a hex comparison between known healthy archives, and my archives that are unreadable. I have discovered that my archives differ in one regards: no footer. Its possible my archives did not complete successfully, which may have been due to the impending failure of the RAID system.
All healthy TIB (at least, one created by ATI 2010) have the following values:
FILE HEADER - CE 24 B9 A2 20
FILE FOOTER - 20 A2 B9 24 CE
The key values, I believe start at offset 0x00000008 - 0x00000014. I think these hold archive settings (full/inc, file order, compression etc). I know 0x00000014 holds the index of the backup. All of my TIBs have this set to 1, as they are FULL, non-incremental.
I have used a hex editor to copy valid headers/footers into a copy of one of my archives and got a different result. It will allow Acronis to load it (using Explorer, this still does not work) but it cannot navigate the archive structure, so its still missing some key information.
If it wasnt for the compression in the TIBs I'm pretty sure I could write a tool to extract the contents. Are any details available on the compression method used?
What I need (and I am sure, thousands of others would also appreciate) is a recovery tool that will work with incomplete TIB archives. There is absolutely no reason why Acronis could not include this functionality, as I'm sure all the key info is in the file headers. Either that or some 3rd party service that can recover TIB data (I don't mind paying for this)
Any help from support staff, or maybe even Acronis developers, would be appreciated
Chad:
The trailing "1" in the file name tells TI that the file is the first part of a multi-part set of files, so it's looking for the others. Normally the "1" is appended to the filename when the backup process starts, and then if it's the only file in the backup set, the software removes the "1" from the filename at the end of the process.
I recall one user on the forum who was able to recover their archive simply by renaming the file. Have you tried that yet?
I think most of us agree that a TIB recovery utility should be on the Acronis priority list.