acronis true image 2020 disk backup will not cleanup

David, sorry but the information provided in your file attachments doesn't show any reason for why automatic cleanup is not working correctly for you!

If you have been changing the automatic cleanup settings, i.e. number of recent versions to keep, then that can cause some strange behaviour where the count of versions can be reset, ignoring existing files to start a new count!

See KB 61844: Acronis True Image 2019, 2020 and 2021: How to delete old backups - which is the recommended method of dealing with unwanted backups if not cleared by automatic cleanup.

There can be lots of confusion around the topic of automatic cleanup which can be better understood if some basic concepts are known!

First:  automatic cleanup only works on complete(d) versions / version chains.  Do not expect individual elements of version chains to be cleaned up, such as incremental or differential files!

Second: automatic cleanup only runs after a new Full backup for the next version / version chain has been created successfully.  This means that there must be sufficient free space available on the storage drive / location to hold a new Full backup image file!

Third: counting of days does not start until after a new Full backup file has been created when using the option to ‘Delete versions / version chains older than X days.’  It does not start for the active backup version / version chain before that point!

Fourth: the simplest & easiest automatic cleanup option to use & understand is to ‘Store no more than X recent versions / version chains.’  The criteria here means that if you set X = 2, then when the X+1 (3rd) version / version chain is created successfully with a new Full backup file, then the oldest version / version chain will be deleted by automatic cleanup.

Example:

Incremental backup task, using Full plus 5 Incremental backups before next new Full backup.

Task scheduled to run daily with automatic cleanup set to ‘Store no more than 2 version chains.’

Day 1 – Full backup created.

Days 2 – 6 Incremental backups created.

Day 7 – Next new Full backup created. 

Days 8 – 12 Incremental backups created.

Day 13 – Next new Full backup created.  Automatic cleanup deletes files created on days 1 – 6.

If the same task used ‘Delete version chains older than 7 days’, then those 7 days wouldn’t start counting until day 7 for the first set of files (version chain 1) and not until day 13 for the second set etc.  So automatic cleanup wouldn’t delete the oldest chain until day 14 in the above example.

Hi Steve,

Good to hear from you again. Unfortunate that I need to. :-) Not sure what else I could have added in the way of attachments.

I changed the number of versions to keep, only after the problem occurred several times. So it can not be the cause. Thought I mentioned that. I also mentioned that I deleted the backup, and built it from scratch, which would also make that irrelevant.

You provided me with a link re. using Acronis to delete old archives. Thanks for that, but like the info. regarding version number changes, that's not relevant. I specifically said that I used the built in feature when I could. And I said that when the feature doesn't list the older archives, I have no choice but to delete them directly. If you know of a way to force the feature to see older archives, be sure to let me know.

Ok, maybe those first two suggestions were copy, and paste. But then... I'm sorry, but all four suggestions are irrelevant. Perhaps I wasn't clear in my post, but these are things I'm already aware of. There isn't an issue with me misunderstanding how Acronis is supposed to work. As far as Acronis goes, I'm a long hauler. :-)

As I ended my original post I should have added that I wanted to avoid the copy, and paste responses. I mean no disrespect, and appreciate your effort. If you have any specific diagnostic tasks, specifically targeting this issue you could recommend, apart from a scorched Earth approach, please let me know. I assume there must be at least one as I've seen this issue all over the forum, and the last time I posted for help a few years ago, it was for the same reason.

Dave

Dave, a lot of the information that I posted above is intended for the wider forum audience as this is a common issue in the forums for some of the reasons given.  I fully accept that you look to have tried to eliminate those reasons for your case and it leaves you with an unresolved issue for the files left behind when they should have been removed.

The next avenue of investigation has to be the logs for your backup tasks covering the dates / times when automatic cleanup should have removed files that met the rules set.

Unfortunately for you and many other users, Acronis are not interested in fixing these problems found in older versions / all versions if True Image now that they are focussed on ACPHO and deemed all else to be out of support.  This means that only workarounds can be offered rather than fixing the code issue that gives rise to the problem in the first place!

Hi Steve,

Thanks for the response.

My guess is they lost interest in fixing this issue years ago, even while older versions were still under support. Now they have an excuse. I appreciate you hanging in there.

I attached a couple logs from days when the specific backup ran. If other logs would be more helpful, please let me know. If you know of any Web sites with good information on this issue, please do the same.

Thanks,
Dave

Dave, sorry but the logs provided offer no help for this issue.

Download a copy of the MVP Assistant log viewer tool and use this to look at the logs to see if they show any issues during the operation process?

The latest version of the new log viewer tool is at the link below. 
MVP Assistant update for Acronis Cyber Protect Home Office (Version 1.1.6.0)

If you have Disks & Partitions backups created on ATI 2020 or later using .tibx files, then look in the Backup Worker logs.

If you have Files & Folders backups using .tib files (or Disk backups from earlier versions using .tib files) or using Cloning then look in the Demon logs.

Other logs are shown by the MVP Assistant under the 'Active Logs' heading of the Log Viewer page of the Assistant.

The log files should be zipped to preserve their original file names if sharing in the forums and would need to be less than 3MB in size, otherwise you would need to share the zip file via a Cloud share service such as OneDrive, Dropbox etc.

Steve,

Thanks for checking.

I'm one step ahead of you. I already downloaded, and installed the log viewer. The question is, if the software doesn't recognize what's happening as some kind of failure, then won't the logs report that all is well? Nonetheless, I'll check them to see if there is anything that appears to be of interest.

I'll start with backup worker logs.

Thanks,
Dave

Dave, the logs you provided were the Demon plus another, both of which held no relevant information.  For a disk backup, the Backup Worker log holds 10 times more detailed information about the task rather than bare bones details saying that the task was started!

Steve,

I was just about to send this backup worker log file which was for the C drive backup.

This operation created the third copy of the archive, which after running, should have deleted the first (oldest) one to keep the version limit to two, which was the setting on 1/23/2022.

It has two sections with highlighted text, which include the words "failed to." Hopefully this helps.

The two other log files that were created for that task on the 18th, and 16th of January contain the same "failed to" sections.

This is secondary, but my OC compels me to get rid of the (1) from the name, if I can.

Thanks,

Dave

Dave, thanks for the backup worker log though I would ask that any further logs should be zipped while retaining their original full name as it will save me some time having to rename them in order to use the MVP Assistant to work with them!

The log does show some issues but these look to be handled by retries after hitting the 'failed to open...' error which triggers the further line in the log saying:

type=cleanup; slices_deleted=1; cleaned_up=502533300224; new_size=1008922419200; id=1;

What the log doesn't show is why automatic cleanup did not run or action any rules that were satisfied.

Regarding the (1) name, this indicates that at some point you used the option to clone the task settings of a earlier task.  This is a limitation in ATI 2020 that doesn't allow a cloned task to be renamed!

One option that would be worth trying here is to delete the current task (after noting all the settings being used), while retaining the existing files that were created by it.  Then to use the option to 'Add existing backup' to select the most recent file for the deleted task, then reconfigure the new added task settings again.

Thanks again Steve,

That sounds like a plan.

I strolled through the logs, and found that almost every C drive backup had a bunch of errors in them, despite the fact that all of them were successful, except for those that ran out of disk space during the backup.

I'm compelled to observe once again the painfully persistent disregard for English that developer's seem to possess. Add an existing backup? One cannot add that which already exists. You can duplicate it, copy it, and a few other verbs, but you cannot add it. Oh well.

While writing this I decided to

• Delete the task
• Create a new one with a new name
• Restore the settings
• Keep the penultimate archive as the last one was a fifth of the size it should have been. Move it to another folder.

I noticed that under the name of the old task the drive destination was listed as F, not G, where the archives are. I removed a hard drive from the PC weeks ago, and the USB external drive changed from F to G. I repointed all of the tasks to the new destination, but the C drive task kept the old path. In fact, all of my backup tasks, save one, still show the old destination (F) in the box, under its name. Yet they all work properly, including the version/chain cleanups. Perhaps as far as the old C drive task that incorrect destination was a red herring. All of the tasks show the destination drive as G in the destination rectangle on the right side of the screen.

When I deleted the task, I decided to let it delete the archives - I had already removed the one I wanted. It couldn't find them. So I just removed the task. It threw up a hairball, recreated the task twice, in each case with the correct drive location in the box with the name. I removed both of them.

I kept the same schedule - Tuesday, and Sunday. I'll let you know how it works out.

Thanks again for your help.
Dave

It's too early to tell if the problem has been resolved with the C drive full backup. The recent backup completed successfully. Unfortunately, not too early for the problem to spread.

Two differential backups (one full, two diffs for each version) set to keep no more than three recent version chains have gone over the limit. The picture shows what I see when I select one of them in explorer. The other pic shows what I see when I select the clean up versions feature.

The two sets of a full, and two differential backups that should have been deleted to keep the count to the setting of three are not seen by the "clean up versions" feature. The one task has started creating the fifth version, when it's supposed to keep no more than three. Yikes.

It seems that not only does the clean up not see them, but Acronis, when it should be reducing the version chains to three, doesn't see them either, which explains why it doesn't automatically delete them, and like the issue with the C drive backup will just keep adding them until the drive is full.

Since at this point I can delete them using Acronis so as not to piss off the lord almighty by doing it through Explorer, I'll do so, and see what happens.

One thing that I find totally, fucking amusing is that the clean up feature tells me that a specific number of backup files could not be found. So that means that it knows the files are there, but then cannot find them, which would indicate that the files are not there, but it doesn't correct itself by stating that files that it expected to find are not there, and yet it still offers the option to delete them. I don't know enough expletives to properly respond to that monumentally fucking gigantic pile of bullshit. But hey it's software. We just run the world on this.

It did it again. It just created the fourth version of the SSD Drive full backup, when it was set to store no more than three versions. At the risk of doing math in public, I'll go out on a limb, and say that four is more then three. If I'm wrong, let me know.

Just as before, the cleanup versions feature doesn't see beyond the limit (3 versions) set for the backup. It offers for cleanup only the three latest versions, and not the first one of four, so I'll have to delete it manually.

On the day (2/08/22) that it created copy three, "My Samsung SSD-003.tibx", it also created an archive named "My Samsung SSD.tibx" with no enumeration, and which is 12kb in size. The 003 archive appears to be of the correct size, and valid.

I attached the log file (as zip) for the 8th, when Acronis created the two archives mentioned above. There was also a "backup worker" log for the 9th (attached as zip) that referenced the C drive full backup. I don't know why since nothing was scheduled for that day.

From a programmatic standpoint, it appears that the task is not "seeing" all the archives, and therefore doesn't automatically delete the oldest one that would take it over the quota for cleanup. It's either not adding the first backup to the relevant database when it is created, or simply not checking the database when it creates a backup, as if there were no version chain limit.

Thanks again for your help.

It did it again. It just created the fourth version of the SSD Drive full backup, when it was set to store no more than three versions. At the risk of doing math in public, I'll go out on a limb, and say that four is more then three. If I'm wrong, let me know.

David, to clarify here: if you set the config to store no more than 3 versions, then automatic cleanup does not run until after a new 4th full backup has been created successfully.

On the day (2/08/22) that it created copy three, "My Samsung SSD-003.tibx", it also created an archive named "My Samsung SSD.tibx" with no enumeration, and which is 12kb in size. The 003 archive appears to be of the correct size, and valid.

The 12kb .tibx file for the version chain contains vital metadata and needs to be left untouched else the whole chain can be corrupted!

See the following KB documents published by Acronis with regards to .tibx files.

KB 63518: Acronis True Image 2020: do not delete first tibx file

KB 63227: Acronis True Image: Do not delete .TIB or .TIBX files outside of Acronis True Image

KB 63498: Acronis True Image 2020-2021: new tibx backup format FAQ

KB 63425: Acronis True Image: Limitations of tibx backups

KB 63516: Acronis True Image 2020: Incremental backups do not create separate files when using new backup format

KB 63445: Acronis True Image 2020: how to view and manage backup versions in new backup format

KB 63444: Acronis True Image 2020 and 2021: tibx backups in local destinations

Hi Steve,

Thanks for the reply.

The fourth backup did complete successfully. That is what I was waiting for prior to posting on this issue again. Thanks for the mention, but I'm familiar with the mechanics of the auto cleanup system, and version chains limitations.

That's interesting about the 12kb file as I can't recall the last time I saw Acronis create that type/size of file. My Quicken backup, which is configured the same way for full backups and the same cleanup settings, has never, as best I can recall, created that type of file. If that file has vital data in it, why doesn't Acronis create it every time, or at least once in all the folders that store the archives?

While I appreciate the links, I don't see the relevance to my problem. If I were a newbie who couldn't understand why I shouldn't manually delete files, they might be of value.

The information I need is what to do to kick it in the ass so that it will start to work properly, and use the cleanup settings that the programmers provided us with. You see all that I have done to resolve this issue, so if there aren't any other known effective steps to resolve this problem, I'll begin to look at the many other applications sold for this purpose.

I assume the two log files were of no value in determining where the breakdown in Acronis is occurring?

Thanks,
Dave

Dave, the two log files don't show anything unusual but also don't show any attempt at cleanup either.

If I look at one of my own backup tasks that did do a successful cleanup recently, then I see associated entries in the Backup Worker log that correspond with the Activity page for the task in the ATI GUI.

The sequence of entries I am seeing starts with an update to the 12Kb metadata file.

29/01/2022 09:22:07:040 AM  Pid: 25680 type=log; level=inf; message=ar#1: opening archive path="\\?\S:\Steve HP\\DriveD.tibx" in rewrite mode (create);

After this the next significant entry has statistical data about the completed backup then the first indication that cleanup is beginning.

29/01/2022 09:22:10:212 AM Pid: 25680 type=log; level=inf; message=ar#1: slices=12 user=322481MB data=218553MB meta=394MB unused=190636MB/8.41% deallocated=1857529MB/81.93%;
29/01/2022 09:22:10:212 AM Pid: 25680 type=log; level=inf; message=ar#1: punch_hole: begin delete unused volumes (last volume: 18);

This is followed by a number of similar entries in the log before a closing statistical entry for the cleanup action.

29/01/2022 09:22:38:441 AM Pid: 25680 type=cleanup; slices_deleted=6; cleaned_up=77777707008; new_size=152665411584; id=1;
29/01/2022 09:22:38:447 AM Pid: 25680 type=log; level=inf; message=ar#1: archive closing;

I am not seeing anything like the above in your logs which suggests that ATI either isn't performing any cleanup or doesn't believe that the conditions for cleanup have been satisfied.

My understanding here is that the metadata file plays a big part in all of this thus if the 12kb .tibx file has been being removed this could cause this or other issues?

Hi Steve,

I'm happy to say that the problem with the C drive backup has apparently resolved itself. No idea what the fix was, except maybe recreating it from scratch, and some good karma from you, but I'll take it.

Thanks again for your assistance, and work. Assuming it bumps your status, I'll mark your last message as solution.

Have a good year.

Dave