Consolidation: 'Failed to open backup' error and other questions/problems
I backup to multiple external USB drives at the moment - at any one time, I only have one of these drives connected. I have a separate Backup specified for each drive (with different names)
I ran a backup last night and this morning found the above error message referring to a backup file that did not belong to the backup that I had just run. Looking in the log it appeared that the backup had worked OK but it was the consolidation that had failed.
To cut a long story short - after wasting several hours (grrr) and much browsing around, it seems that the 'database' in which TI stores details of each backup, gets corrupted and for a given backup, references files that don't belong to that backup.
And that the way to clean this up is by trying to run the recover function and clicking Ignore for every file that it asks you open which it can't find.
In this case, there appeared to be at least 10 files (based on the number of times I had to click Ignore and also the error messages that appeared under Acronis True Image console).
So I have some questions:
0. Is my diagnosis correct?
1. Why does the archive database get corrupted in this way? (And why don't Acronis fix it)
2. Is there a better way of cleaning up the archive database (And if not, why don't Acronis have a function to do this)
3. It seems that consolidation doesn't work (lots of posts saying don't use it). Can I confirm that consolidation is used if you choose the 'Delete version chain older than x days' or 'Keep the size of the backup no more than xxx GB' but is *NOT* used for the 'Store no more than xx recent version chains. Is this correct (Questions for Acronis: why doesn't consolidation work and why don't you document the circumstances when it is used and when it isn't used)
4. What happens in the consolidation process if the older backup has lots of files that have now been deleted on the source machine and which are not present in the most recent backup - are these kept in the consolidated version (and why aren't things like this documented).
Overall, once again I find myself feeling very, very frustrated with Acronis TI. I have been using it for years and stick with it because I know it but I really can't afford the time that it requires to investigate problems like this and it makes me nervous. I want a product that I can trust and Acronis doesn't feel that like that product
Sorry about the rant but I am just feeling very annoyed at having wasted so much time.
Any replies, if only to the practical questions, would be greatly appreciated.
Many thanks.
Richard
Just had the same problem again - same version of TI software. Took me an hour or two sort out (because I had forgotten the details of how to fix - it was only only when I came back to the forum and found my original post that I was able to fix).
I sincerely hope that Acronis have done something about this problem in TI 2015 because it is enormously frustrating. To summarise:
* please fix problem where the list of backup files associated with a backup gets corrupted
* please improve the quality of the error messages - the current error messages (see attached) give absolutely no clue as to how to fix the problem (and this is generally true of all TI error messages)
* please provide a menu option for a backup 'View/Fix backup file list' or similar so it is more obvious how to fix the problem (rather than knowing that you need to start a Restore in order to fix this problem.
* when trying to clean up, TI displays a message 'Warning: Cannot find version 4'. This is completely useless. It should display the name of the file that it is looking for as you have no way of knowing what file is required and whether it is a legitimate request, or the result of the Backup File List getting corrupted
Ha - spoke too soon. True Image has now done something incredibly stupid which explains what causes the backup file history to get corrupted but doesn't explain why.
WHAT TI HAS DONE: WHEN I CREATED A NEW BACKUP TO A DIFFERENT DRIVE, IT MOVED THE BACKUP FILE HISTORY FROM A PREVIOUS BACKUP (WITH A DIFFERENT NAME) AND APPENDED IT TO THE NEW BACKUP.
I WOULD BE DELIGHTED IF SOMEBODY COULD EXPLAIN THE RATIONALE BEHIND THIS AND/OR HOW TO STOP THIS HAPPENING.
Slightly more detail:
- I normally backup to a large USB disc using a backup called (say) BACKUPLARGE
- I also keep a USB drive off site which I bring back periodically and back up to as an extra precaution
- I brought this back yesterday and created a new backup called (say) BACKUPOFFSITE and I ran a backup and verify last night (I did this because I had replaced the hard drive on the laptop with a larger drive)
- After the verify had completed, I noticed that the backup size reported by TI was over a terabyte - it should have been c 300-400GB and that the backup version was 28!!! (despite this being the first backup for this backup name) (I also noticed that the last version number for BACKUPLARGE was 27 << not looking good here)
- I then try to use the Recover files option and lo and behold it couldn't find a large number of backup files
Conclusion: for some completely bizarre reason TI has decided the new backup (BACKUPOFFSITE) is the same backup as BACKUPLARGE and has moved all the backup files associated with BACKUPLARGE to BACKUPOFFSITE (despite the backups having different names, being on different discs and having different disc letters)
This is confirmed because now when look at BACKUPLARGE in TI, it tells me that it is 'not backed up yet' (because it had moved the backup file history to BACKUPOFFSITE). Grrr.
I have partially restored the situation by going to the backup files in Explorer and using the Recover option there - but this only brings back the most recent backup chain. It I try to restore the previous backup chains from Explorer, TI creates new named backups - it doesn't add them back into BACKUPLARGE.
This is so annoying. Can anybody explain why TI does this and how to avoid it happening in the future.
I am still on TI2013 and using Windows 7 but have no expectation that this will be fixed in more recent version.
Richard
Actually, there is one thing wrong in what I wrote above.
TI doesn't move the backup files associated with the first backup (BACKUPLARGE) to the second backup (BACKUPOFFSITE), It treats the second backup as an extension of the first backup - rather than maintaining separate histories for each backup, it simply adds the new backup file to the history which is then shared between both backups.
So when checking whether I could recover files from the second backup (BACKUPOFFSITE) and it told me it couldn't find all the earlier versions (becauses they were on a different disc that was no longer mounted, and were associated with a different backup), I told it to ignore these versions which caused TI to delete the files from its backup history and in so doing, deleted them from the history associated with the first backup (when then said 'No backups').
I cannot understand why TI is doing this. Any suggestions? And any suggestions for stopping it doing this.
Richard
I am having the same problem. Can you tell me if you ever resolved the problem and, if so, how?
Wray, welcome to these user forums.
This type of problem is most likely associated with using more than one backup drive with a single Acronis backup task which results in corruption of the Acronis Database files / information.
This is even more likely in later versions of ATIH than the 2013 version the original poster wrote about, as Acronis records the unique drive identifier for the first backup drive set for a task when created. This UUID information is then matched for any further drives that are presented to the backup task and error messages will be given when it isn't the same value as the one stored.
The best advice is to have separate backup tasks for each unique backup drive and never mix these.
Further pre-allocate specific drive letters to each unique backup drive from later in the alphabet, i.e. those normally unused when you plug in temporary devices such as USB memory sticks etc. This should result in the same pre-allocated drive letter being given to each different drive each time it is connected.
Once you have this issue, then you can try validating each of your tasks to tidy up the database information, but the better approach is to create whole new tasks as above, with completely different names and targets, then remove all the older tasks, to make a clean start for the database information.
I think I already resolved the issue by deleting the archives.xml.
When I changed the version chain backup destination drive I deleted and recreated the backup job thinking that would prevent any continuity conflict. Apparently the cleverness of the software uses the archives.xml to match and track using a UUID.