TIH2011 Started Consolidating Version Chains Instead of Deleting Them
I am using TrueImage Home 2011 Update 3 (Build 6942).
I run several scheduled backups of large amounts of data each day. The original data is contained on a local drive and all of the backups are saved on a second local drive.
Each backup uses the following backup scheme:
Custom Scheme > Incremental > Create a full version after every [6] incremental versions > Store no more than [1] recent version chains
Under this scheme, a new full backup is created once a week and the previous full backup and incremental versions are automatically deleted afterwards. This leaves me with only 1 version chain of each backup at a time.
For about 20 weeks, this scheme worked properly. Each week a new backup would be created and I could keep count based on the numbers appended to the file name. Week 1 was Backup.tib, week 2 was Backup(1).tib, week 3 was Backup(2).tib, and so on.
Now it does something slightly different (and the settings haven't been touched). Each week it creates a new full backup as intended, appending "(1)" to the end of the backup's name, deletes the previous version chain as expected, but then it consolidates the newly made, single backup file for some unknown reason.
This consolidation process simply recreates the same full backup file it just made and therefore doubles the time for each backup to complete. The one difference between the consolidated and pre-consolidated backups is the file name, which goes from Backup(1).tib to Backup.tib again after consolidation.
I am unsure if this is the result of installing the latest software update, hitting an artificial limit on the number of backups, or discovering a bug that exists in the software. I have enough HDD space on the destination drive for the largest backups to exist multiple times, so running low on HDD space is likely not the issue.
Anyone experiencing the same issue? Any bright ideas on how I can correct this?
I'd appreciate any help if you can offer it. Thanks in advance!
If that doesn't work, move your backups to another location and then delete the task(s) and recreate them.
Thanks for the screenshot. That is how I currently have my backup scheme set up (the only change is that I "store no more than [1] recent version chains" instead of 4). The option to "Do not delete the first version of the backup" was not enabled during task creation.
The scheme used to work properly, but this behavior changed sometime within the past month. It now unnecessarily consolidates the full backup file after the previous version chain is deleted.
In detail, this is what I'm seeing happen:
Day 1 - Backup.tib created (FULL)
Day 2 - Backup2.tib created (INCREMENTAL)
Day 3 - Backup3.tib created (INCREMENTAL)
Day 4 - Backup4.tib created (INCREMENTAL)
Day 5 - Backup5.tib created (INCREMENTAL)
Day 6 - Backup6.tib created (INCREMENTAL)
Day 7 - Backup7.tib created (INCREMENTAL)
Day 8 - Backup(1).tib created (FULL)
- Previous version chain deleted (Backup.tib - Backup7.tib)
- Backup(1).tib consolidated (FULL) and renamed Backup.tib
Previously the last step on Day 8 didn't happen (because consolidation of a newly created full backup is unnecessary), but now it does and I don't know why (consolidation is disabled under that setting). I have sufficient free HDD space for extra chains to be created. My best guess is that there may be a bug within the latest software update.
No matter what may be causing it, I just hope there's a solution out there for it... :)
PS - I should also probably mention that these tasks are File Backups, not Disk or Partition Backups, in case that changes anything.
If that doesn't work, move your backups to another location and then delete the task(s) and recreate them.
There were two things I was saving as last ditch efforts, as I hoped it wouldn't get to that point:
1) Reverting to a previous software build
2) Deleting ALL the tasks and recreating them (along with their backup files)
Based on your feedback, maybe I'll first create a new backup task as a test and manually run it (8 times to simulate a week's backups) and see if anything different occurs, or if it has the same behavior as the current tasks. I'll post results once complete. Thanks for the help!
UPDATE: I created a new backup task and received the same results as my current tasks. After deleting the previous version chain, it consolidates the full backup file unnecessarily: Backup(1).tib FULL created --> Previous Chain deleted --> Backup(1)_8F0A769B-51E7-4A98-B3C9-1C49AF5125291.tib created (during consolidation) --> Backup(1).tib deleted --> Backup(1)_8F0A769B-51E7-4A98-B3C9-1C49AF5125291.tib renamed Backup.tib
seanbob,
Are you positive you have clicked on "turn on auto-cleaning" and not on "auto-consolidation"? In other words are you positive you see exactly the same screen shot as in post #1 above?
It seems you are positive from your posts, but since both workflows are kind of similar and the bifurcation point is when you select whether to *always* do incremental, vs. *create a new full after... incrementals".
seanbob,
Are you positive you have clicked on "turn on auto-cleaning" and not on "auto-consolidation"? In other words are you positive you see exactly the same screen shot as in post #1 above?
Yeah, I'm pretty sure...
Just in case, I've attached a screenshot from one of my backup tasks (all use the same backup scheme). Having done quite a bit of debugging/testing in my time, I know it never hurts to double-check these things with a second set of eyes.
Another interesting note that may help troubleshoot...
I changed one of the backups' automatic cleanup settings from "Store no more than [1] recent version chains" to "Delete version chains older than [7] days" and it did work as expected. There was no consolidation following the full backup creation and all previous chains were deleted.
This leads me to believe that a new bug was potentially introduced for the "Store no more..." cleanup option in the most recent update, which causes consolidation to start for some reason.
UPDATE: From further testing, the consolidation may only be happening when the "Store no more..." option is set to "1". I changed it to "2" and the problem disappeared there too. (Unfortunately, given the size of the backups I'm storing, it's impossible to store more than 1 version chain of each.)
Ah! I get it now. I missed the choice of 1 most recent backup version chain.
What you are seeing is not a consolidation. It is the same process you would see if you had chosen the "single version" default scheme.
ATI will always first create the full backup before deleting the existing backup chain. So it creates a backup with a temporary name, then erase the previous backup, then rename the temporary file.
I never noticed it was working this way in previous builds for the case of an incremental backup. Maybe it is a change in the last build for the case of "1" as a value of the number of chains to retain...
I guess you won't see this if you use 2 chains.
What you are seeing is not a consolidation. It is the same process you would see if you had chosen the "single version" default scheme.
ATI will always first create the full backup before deleting the existing backup chain. So it creates a backup with a temporary name, then erase the previous backup, then rename the temporary file.
I never noticed it was working this way in previous builds for the case of an incremental backup. Maybe it is a change in the last build for the case of "1" as a value of the number of chains to retain...
Thanks for the additional help, but I guess I'm still confused about this: Should it be creating TWO full backup files as part of the automatic cleanup?
What I'm seeing is a new full backup being created, the existing chain deleted, and then a second new full backup being created with a temporary name. When the second full backup completes, the first full backup is deleted and the second full backup is renamed.
Technically, there isn't a problem with the results, as I still end up with the single chain full backup that I expect, but during every clean up it's now creating two full backups as part of the process (instead of one), doubling the time it takes the backup to complete. Prior to the latest build (I suspect, as this new behavior began happening within the last month), it would only ever create the first full backup, and never the second one with a temporary name.
seanbob,
Maybe you already have them but I would strong encourage you to have more than one backup chain.
Reasoning:
1. A malfunction via corrupted file.
2. Often times, considerable time can lapse before a missing or problem file is discovered. You want some older archives to be preserved for the sake of safety.
The normal procedure for Acronis is to do create a replacement full before deleting the older file so there is never a time during the this phase where you have no actual files. The temp file becomes the new replacement.
What I'm seeing is a new full backup being created, the existing chain deleted, and then a second new full backup being created with a temporary name. When the second full backup completes, the first full backup is deleted and the second full backup is renamed.
Well, this is abnormal and doesn't make sense.
Try to uninstall ATi, reboot, make sure that the Acronis/TrueImageHome directory is empty (it could be under c:\programdata on Win7 or Vista, or C:\documents and settings\all users\Application settings on XP), and reinstall ATI 2011. If that doesn't solve the issue, I am running out of ideas.
It really sounds like he's getting one more backup than he's supposed to.
Possibly the consolidation algrithm can't handle unity. But, as Grover pointed out, always a good idea to have more than one backup. If you don't have room for two, consider getting a bigger drive. Just one bad byte in the backup set and the whole chain can be unusable.
What I'm seeing is a new full backup being created, the existing chain deleted, and then a second new full backup being created with a temporary name. When the second full backup completes, the first full backup is deleted and the second full backup is renamed.Well, this is abnormal and doesn't make sense.
Try to uninstall ATi, reboot, make sure that the Acronis/TrueImageHome directory is empty (it could be under c:\programdata on Win7 or Vista, or C:\documents and settings\all users\Application settings on XP), and reinstall ATI 2011. If that doesn't solve the issue, I am running out of ideas.
I will give this a shot today and report back. Thanks!
Uninstalled TrueImage and rebooted. "C:\ProgramData\Acronis\TrueImageHome," as well as the "Application Data/Roaming/Acronis" and "Program Files (x86)/Acronis" folders were all empty. Reinstalled the latest build of TrueImage and rebooted. Created a new backup task and the same issue presented itself. Creates a full backup and then creates a second full backup (which TI reports as "consolidating backup" on the status screen).
I will uninstall TrueImage again and reinstall the previous build to see if that changes anything -- as it was working properly before. Fingers crossed.
Sean,
You might have discovered a bug with that specific case of a single most recent version to keep (which should do what the single version standard scheme does)
Do you see the same issue when you change the number of chains/version from 1 to 2?
If you create a task that is an incremental task, creating a new full after a single incremental, retaining only 1 most recent chain, does it work?
When you use the single version scheme, do you see the same pattern?
Possibly the consolidation algrithm can't handle unity. But, as Grover pointed out, always a good idea to have more than one backup. If you don't have room for two, consider getting a bigger drive. Just one bad byte in the backup set and the whole chain can be unusable.
I too agree that backups should have backups. Due to the large amounts of data I'm backing up (1.5 TB), I'm forced to use a single chain, but I believe I have sufficient redundancy in place (somewhat unconventionally perhaps) for this to not be a problem.
To explain briefly: My backup HDD size is 2 TB. I keep a quarter of it free for new full backups to be created properly, and the rest of the space is devoted to storing 1.5 TB worth of file backups from my other internal drives. About once a week, I transfer those backup files to an external hard drive and place that drive in a safe deposit box off-site.
Since the backups are not disk/partition, but file backups, accessing them should only become necessary in the event that something happens to the primary file on the other drive. And if, for some reason, the backup files become corrupted, then I have a previous backup chain stored off-site to fall back on. I also check my version chains once a week using TrueImage to make sure that all is well.
So if, for some reason, the file goes bad on one drive, along with the backup on another drive, in addition to a second backup on an external drive... then that's just pure rotten luck! :)
Sean,
You might have discovered a bug with that specific case of a single most recent version to keep (which should do what the single version standard scheme does)
Do you see the same issue when you change the number of chains/version from 1 to 2?
If you create a task that is an incremental task, creating a new full after a single incremental, retaining only 1 most recent chain, does it work?
When you use the single version scheme, do you see the same pattern?
I think you're right that it could be a bug in this latest build.
When changing the number of chains from 1 to 2, the problem disappears. It no longer says "consolidating backup" on the status screen and only creates one full backup file during the process.
When creating a new full after a single incremental (and only storing 1 chain), it creates two full backups instead of a single full backup. The second is shown as "consolidating backup" on the status screen.
When using the single version scheme, there is no problem. It creates a single full backup alongside the previous full backup (no cleanup or consolidation).
I uninstalled TrueImage again and reverted to the previous build (Update 2 - Build 6868). The problem doesn't present itself anymore, so this odd behavior was indeed introduced in the latest update.
Does anybody know the best way to submit a bug report to the developers about this issue?