ATI 2020 does not delete old version chains!

Please post more details of your backup settings.  Schedule, Scheme, Method, and clean up rules. 

This information will help in getting a more definitive response.

I have uploaded a screenshot of the settings. Let me know if you need anything else. Thanks.

A little more information would be helpful.  What kind of backup - disk & partitions, entire PC, files & folders?

Which backup format is used - .tib or .tibx?

What is the target device- a local drive, a NAS, an FTP server?

The backup is a mirror of the C: drive (the Windows 10 drive) on Win 10 Pro PC. The target is an external USB drive that is mapped as R:. All backup files are .tib.

So if your backups are all .tib then this task was created by a previous version of TI so which version created it?

If your backups are all .tib then this means too that you chose to "Add existing backup" to bring the previous backup files and task into the 2020 GUI task list.  This action would require that you "Reconfigure" the backup.  Can you explain what steps you took in performing the reconfiguration?

I don't remember any reconfiguration step. I just installed the 2020 upgrade and kept going. The problem with the old version chains not being deleted existed in 2019 too. I don't know exactly when or why ATI stopped deleting old version chains. Are you telling me that I need to recreate all of the backup jobs in 2020?

William, what actual files do you have on your backup drive for this task?
How often is your backup task running?

Your settings say to create a new Full backup after 6 Differential backups, and to store no more than 4 backup chains.

This means that you should see the following files:

4 x Full backup files + 4 x 6 Differential files (24)

When the next Full backup file is created, then ATI should remove the oldest chain of 1 Full & 6 Differential files.  This only happens after the 5th Full backup is created successfully.

If you have modified these retention settings during the life of the task, then this can cause the counts to be reset and result in more files being stored than expected.

There is no need to recreate all your backup tasks just because you have upgraded to ATI 2020 as the jobs brought forward from ATI 2019 will still continue to work as they did before.

Any new tasks you create on ATI 2020 will now use .tibx files if making Disks & Partitions backups (Files & Folders backups continue to use .tib files as before).

If you need to recover space for you new backups, then you should use the new Clean up versions tool provided in ATI 2019 and 2020.

See KB 61844: Acronis True Image 2019 and 2020: How to delete old backups for more details.

Thank you Steve.  I cannot add anything more.

Thanks Steve. You may have found the problem. I was not aware of the new option to delete old versions within ATI and have deleted them using Explorer. I have now deleted the old versions within ATI so that what ATI shows and what is on disk match. I'll see if the auto-deletion works from now on and if I have to delete old versions in the future will do so from within ATI.

I've had the same problem for YEARS and probably could search and find old threads asking the same thing over multiple versions.

This is/has been a known issue.  So do you think it will ever be resolved?  Or is it just hit or miss...  If you're BU Chains delete automatically, fine.  If they don't...   Gee, can you tell me the same thing everyone else has said before you.

As with William, for all of my (many) upgraded ATI just loads an goes on.  So if the issue is that the BU profile needs to be updated with each release, then I think that should automatically take place with the installation of the release.

So if the issue is that the BU profile needs to be updated with each release, then I think that should automatically take place with the installation of the release.

Pete, this issue has nothing to do with backup profiles or upgrading the version of ATI - it is caused because users delete ATI backup files outside of the ATI GUI or not using the tools provided to manage those files by ATI.

Deleting files in this way causes errors in the database which ATI uses to track files created by each active backup task.

I accept that this is a long standing issue and has been explained many times before but unfortunately users continue to do the same actions even when new features such as Acronis Active Protection try to prevent the files from being deleted.

I am sure that Acronis could make changes to the design of ATI to cope with these user actions but in all honesty I do not see them doing so, and the change to .tibx files in ATI 2020 & beyond will make these actions of greater impact by potentially rendering backup chains unusable due to the additional dependencies now present for .tibx backup chains.

Hi Steve,

I have the same problem as the users on this thread.

I'm curious about the logic behind your conclusion. You mentioned that the problem of more chains being created than specified in the settings being caused by users deleting extra chains through Explorer. The problem with that conclusion is that they would have to have the extra chains before they used Explorer to delete them.

While that might cause the problem to continue, it cannot create it as the extra chains existed before the improper deletion.

I don't see how the creation of extra chains beyond what is specified in the settings, as having a cause other than the application ignoring the settings.

Thanks, Dave

David, there are a couple of different factors at work here with this type of issue:

1. Making changes to the backup task retention settings, i.e. changing the number of incremental files to create before making a new full backup, or the automatic cleanup settings etc.
    
2. Deleting unwanted backup files outside of ATI using Explorer.

The first factor can cause internal counters to be reset and result in more files being created than were expected.  This in essence is a code issue in ATI that has been present for multiple versions without being resolved.

The second factor causes other issues due to the internal tracking database being out of sync with the actual files present for tasks shown in the GUI.

The second factor has been addressed by the introduction of the Clean up versions tool in ATI 2019 and later versions.  Using this tool deletes the unwanted files while also keeping the database updated.

Existing code issues in any version older than ATI 2021 will never be fixed by Acronis for those older versions as they are out of support.  ATI 2020 and later introduced the new .tibx file format for Disks & Partitions backup tasks, where the first issue may be addressed?  I haven't seen any reports of that behaviour in either 2020 or 2021 versions that I can remember?

My own personal experience is that my backups have been setup and will run without further intervention.  When I do want to change any significant settings, i.e. retention or cleanup, then I normally start with a new backup task that uses the required settings rather than changing the existing working task.

Steve,

Thank you for your reply.

When I use my left turn signal, it causes the car to apply the brakes. This has been an issue with their code for years. The difference here is that the buyers of cars won't put up with that bullshit, so they're now out of business.

You'll have to forgive my sarcasm, and profanity, but considering that their code was created to do backups, the fact that it has a problem with standard settings for backing up, (settings they created) and has for several versions, is fu&$%^ing outrageous.

It took them till 2019 to add a tool for deleting the extra copies that the code makes because it can't follow its own directions? Forget about the app simply checking before it begins the backup to make sure it sees the files it expects to, and when it doesn't, simply pause, update the database with the new inventory, then continue. Heck, they might even think enough to send the user an email to let them know what happened, and maybe even take the time to tell the user, don't delete the files, and here's directions on how to find a tool we gave you.

I'm running a recently purchased 2020 version, so now you've seen at least one report. Sorry to go off topic, but if a software company learns of a serious issue with a version no longer in support, they should be required by law to provide a fix. Recalls on cars don't have a time limit.

I has months of smooth sailing until my backup drive ran out of space. Then down the rabbit hole.

Do you know if that tool can be used to manually update the database if a user has manually deleted files?

Thanks Steve, Dave

Well said David. It is one thing for those who live inside ATI  to learn all the bugs and work arounds but for the casual user it is beyond annoying to have to contact support every time ATI falls over (which has happened to me more than once). I would pay for an upgrade where the entire development cycle was devoted to improving the robustness of the product instead of adding new features.

Do you know if that tool can be used to manually update the database if a user has manually deleted files?

No. The clean up versions tool only manages the database entries for the files it deals with.

You can force the database to be rebuilt using the steps described in KB 60915: Acronis True Image: repairing program settings

Sorry to go off topic, but if a software company learns of a serious issue with a version no longer in support, they should be required by law to provide a fix. Recalls on cars don't have a time limit.

If you are using a perpetual license version of ATI 2020 then the terms of that license apply and give up to 1 year of free support while the product is 'in support'.  This is significantly better than the 30-days of support from date of purchase they used to give to users!

If you want longer lasting support, then you need to have a subscription license which gives this but many fixes get resolved in the next version that Acronis release, which subscription users get for free while their subscription is active!

There is no comparison between safety defects on cars and software products with code issues unless that software is driving a Boeing 737 Max airplane and causes it to crash and burn literally!

William Todd wrote:

Well said David. It is one thing for those who live inside ATI  to learn all the bugs and work arounds but for the casual user it is beyond annoying to have to contact support every time ATI falls over (which has happened to me more than once). I would pay for an upgrade where the entire development cycle was devoted to improving the robustness of the product instead of adding new features.

Thanks William. My opinion is admittedly anecdotal, but I believe that the majority of users would advocate for improvements in the reliability, and operability of software for the same cost as an upgrade that changed, and moved icons and links, and added features that are sometimes of value to some users.

The difficulty is getting someone to stand up at a board meeting to advocate for the same thing knowing that their pleas were for an approach that is new, and will sound far riskier to the people in the room than it actually is. Nothing short of a movement, or paradigm shift in software development could create an environment in which that idea wouldn't suffocate in seconds.

Not to beat a dead horse, but the feedback machinery is also against that kind of change. All of the means by which feedback is provided to developers places that feedback as far downstream as possible, with little to no chance of making it all the way to the head of the river.

We need legislation that makes software developers as liable as all other manufacturers are when their products cause harm. Imagine buying a chainsaw, and having to sign an agreement that states that if your are injured, maimed, or killed by the chainsaw, even if you followed all of the safety guidelines, and the injury or death was due to a design flaw that we knew existed at the time of manufacturer, you agree to have no civil remedy.

Hi Steve,

I'm back again. This time after following the steps to repair program settings, which appeared to go off well. Thanks for the recommendation.

The next backup that occurred automatically, which I named everything else, gave me an error message, which I pasted into a word doc., and attached. The essence of its claim was that Error 0x1e50023: The specified file does not exist: F:\My Backups\Everything Else\Everything Else_diff_b28_s2_v11.tib.

After sending that error message via email, it then sent me exactly the same error message again, word for word, a few minutes later. The only difference being that the file it now couldn't find was s3_v11. Note that none of the files in the previous chains have as part of their name v11. They all have v1.

Acronis decided that the appropriate response to not finding these files was to create two differential files of exactly the same size. You can see them in the screen shot in the docx. You'll be able to quickly determine by that screen shot that this is a differential backup with one primary, and then two differentials. I will also add that the backup scheme is set to keep no more than three recent version chains. It has five.

I attempted to use the cleanup tool that you mentioned in order to delete the old archives, but as you can also see in the docx that tool sees only the most recent, thereby removing that option. Since the app appears to no longer know that the older archives exist, I wonder if I would be able to delete them through Explorer, (I use cubicexplorer as it allows multiple tabs) with no negative outcome.

I'm willing to delete the archive files the tool doesn't see, and let the tool delete the rest of the archives, so that the backup folder would be empty, and start anew, if you think that the most expedient course of action. I'm assuming that if I manually delete the old archives, and use the tool to delete all of the archives that the app appears to know about, that when it finds an empty folder, that will be exactly what it expects to find, and thus no more errors.

Thanks again Steve for all your assistance. BTW - any idea why they formatted these text boxes so that enter always takes you down two lines, as opposed to the traditional one?

David, looking at your log file information, the error is being reported when the task is attempting to validate the successfully created backup image file.

2020-10-17T04:30:47:979-04:00 18820 I00640000: The following backups have been successfully created: "F:\My Backups\Everything Else\Everything Else_diff_b28_s2_v1.tib"

2020-10-17T04:30:49:421-04:00 18820 I000B0402: Validate Backup Archive Location:      "F:\My Backups\Everything Else\Everything Else_diff_b28_s2_v1.tib" 

2020-10-17T04:30:49:422-04:00 18820 I01E50023: Error 0x1e50023: The specified file does not exist: F:\My Backups\Everything Else\Everything Else_diff_b28_s2_v11.tib.

The _v11 notation is strange and has been reported many times, but appears to be being used as a 'place holder' because ATI can't find the correct file(s).

I would suspect that this ties in with the problem with the Clean up versions tool not showing all the actual files that are stored on the drive, which in turn indicates that the internal tracking database is out of sync.

Did you follow the steps in Method 1 of the KB document referenced above, to force a rebuild of the database files?  This should have helped resolve these issues but you would still need to run a manual validation of the task after the database rebuild, to get it to be repopulated with correct information.

The text input box in the forum defaults to using paragraph format, hence the 2 line gaps - you can force a single line by using the shift key and pressing enter.

Hi Steve,

Thanks again.

Yes, I followed the steps in method one. However, I did not run a manual validation as that's not mentioned in the instructions. Is a manual validation different from the validation you can select to happen after each backup? If not, how do I do a manual validation?

Shift/enter, of course, of course.

Nothing keeps a sense of humor strong better than software. The clean up tool could look into the relevant folder, and observe the files present, but noooo, the developers thought it better for it to look into a database as opposed to reality. If you're using a tool like this odds are that something has gone wrong, so whatever you do don't rely upon a database that might be corrupt. It can't find a file so it changes the name to something that doesn't exist first, then reports it can't find the file whose name was just made up.

At this point should I jump to step two?

Thanks,
Dave

Dave, a manual validation is an option in the drop-down menu for each backup task shown in the ATI GUI - look for the caret (v) to the right of the task name and click on this to show the menu options.

The suggestion about doing a manual validation was to have the database repopulate with information about the files for the backup task after using the KB method to force a rebuild, but this should also happen if the backup task is run.

The database itself is only used by the ATI GUI application - it has no relevance if using the Acronis Rescue Media, so I guess that the developers elected to base the clean up versions tool on the database because that too is only available in the GUI, but it could have been flexible to allow for detecting other files in the same destination when using the same name as the task!

You are welcome to try the other methods in the Repair KB document though I am not certain that they will be guaranteed to resolve the _v11.tib file issue!

Steve,

I ran the manual validation. It reported that it had completed. The files in the backup folder I've been working with did not reduce. The archive deletion tool saw the same erroneous number of files that it did previously. Nothing changed.

When a backup failed because my 4TB external drive had no room left, I threw up my hands, and manually deleted the old archive files myself.

Thanks again for your help. No need to reply to this message. I'm going to let it ride, so long as it makes usable backups until I decide to fix it again.

Thanks,
Dave

Dave, validation doesn't perform any cleanup actions other than reconciling the information held in the internal database.  You shouldn't be deleting any files using Explorer but using the new Clean up versions tool if automatic cleanup didn't do the job.

Hi Steve,

I received an error this morning that a backup failed due to The quotas are violated.

All of my backups are now not deleting old archives as per their settings.

As of September, it is no longer deleting ANY old archives. I always provide a lot of information, but this one is that simple.

Thanks,
Dave

Dave, for quota issues there are 2 things to check:

1. How much free space is actually available on the destination location / drive?
   This needs to be sufficient to allow a new Full backup image to be created before any automatic cleanup can be performed as ATI never deletes old files first!
    
2. Have you set a value at the top of the ATI GUI task Notifications page for free space?
   This will be taken into consideration by the task and it will not continue if there is insufficient free space to allow for the size specified.

Hi Steve,

I'm struggling to continue this dialog. 244 Gigs, out of six terabytes. It is so low because, as mentioned, none of the backup routines are deleting the archives/chains that should be deleted as they create a quantity of archives/chains above the quantity specified to be deleted.

Not to be snippy, but I don't see the relevance of your question about notifications. If the application were deleting the archives it is set to delete, there would be no need for any notifications. I don't need a notification that my house has burned to the ground when I have a fire alarm that should have called the fire department long before that happened. I need to know why the alarm didn't work.

To nonetheless answer your question - yes. I have all backups set to notify me if the available disk space drops below 10 gigs. So long as it deletes the chains as specified, I'll never run out of room.

What I really need at this point is to know why the application is ignoring the settings to delete old archives and chains for all of the backups, and just adding archives as if there were no specification to do otherwise, and how to get it to start following that setting.

Thanks,
Dave

I have all backups set to notify me if the available disk space drops below 10 gigs.

Dave, please disable this disk space notification then retry that backup to see if the automatic cleanup does take effect then.

244 Gigs, out of six terabytes. It is so low because, as mentioned, none of the backup routines are deleting the archives/chains that should be deleted as they create a quantity of archives/chains above the quantity specified to be deleted.

What are the sizes for the full backup files for your backup tasks here?

What are the Backup Scheme and cleanup settings being used?

Automatic cleanup will only run after a successful new full backup file has been created, hence the questions in this area.

One more thing. For all of the backups, the clean up tool does not show all of the archives. What a disaster.

Sorry Steve, but I don't see the relevance of your questions.

I know you're not being paid to help me, and I appreciate that, but I've been backing up data, at home and at work for a couple decades.

The backups, so long as there's enough free space, all work. None of the backups delete the old chains, as per the settings, even after changing the number of chains to keep a couple of times.

Some are differentials, others are full, like for Quicken, or my C drive. Quicken is set to keep four full. I just deleted four of eight on the external drive.

I'll gladly take well-informed advice on what will fix this issue, otherwise you can cut me loose, and I'll either just keep manually deleting, or wipe the external drive, and reinstall Acronis.

Thanks,
Dave

Dave, I can only try to help you by understanding all the settings that you are using, hence my questions seeking to establish what these settings are.

I too have using backup & recovery applications for many years, using ATI since version 9.0 and other software before that.  My own backups do perform automatic cleanup correctly and are to all intents self-managing without the need to take any manual actions.

The one key rule about automatic cleanup is simply that nothing gets deleted until after a new Full backup has been created according to the rules set for the backup scheme being employed - this is regardless of whether there is sufficient free space or not, though in the latter case, cleanup will not run if the new backup cannot be created!

The easiest / simplest cleanup rule to use is: "Store no more than X recent version chains"

With this rule, If I set X = 3 and am creating an Incremental scheme that makes 5 incremental files then a new Full file, I will need space on my destination drive to store 3 backup chains comprising 3 full files plus 15 incremental files plus 1 further Full file before the oldest chain of 1 Full + 5 Inc files gets deleted.

If you use the alternative rule to "Delete version chains older than Y days" then you need to understand that day 1 of those Y days does not start counting until after the next new Full backup file for a new chain has been created!

Aloha from Hawaii! I just discovered and read through this whole thread, and David's situation and experience is eerily similar to mine. My 4TB backup disk is full because somewhere in the process ATI stopped deleting my old backups.
I tried to set ATI up so that it would do a full backup monthly and incremental backups weekly in between, and also delete all backups before the previous one - i.e. so that my backup drive should contain only the current full backup, the previous full backup and up to four dependent backups since the previous full backup. Since each full backup is about 0.9TB, this should use <3TB on the backup drive. That seemed to be working up through July, when for some reason (maybe upgrade to V2021?) it stopped deleting the old backups. There are now 6 .tibx backup files on the disk (including the incomplete current backup attempt). Since the drive filled up early this month, no backups have completed.
I want to delete the earlier backups, but the clean up versions tool doesn't seem to work, apparently because it can't complete a full backup first. I understand that it's not good form to delete the old backup files that I don't want anymore using File Explorer (or whatever), but why shouldn't I do that to clean up enough disk space so that the clean up versions tool will work - at least for the intermediate unwanted backups.  There must be some way (maybe only "using the steps described in KB 60915: Acronis True Image: repairing program settings"?) to then correct the discrepancy within ATI regarding the files that I sinfully deleted externally. 
Steve, I really appreciate your concise and clear answers to all the questions Dave has raised, almost all of which mirror my own issues.  I'll really appreciate your response to my thought about externally deleting old backup files to free up disk space so the program can update current files and, hopefully, clean up the remaining previous versions.

Mahalo (thanks!) for your help,

Tom

Tom, welcome to these public User Forums.

There is a known issue with the 'Clean up versions' tool that means it cannot work correctly if there is too little free space on the storage drive location!

The work-around for this issue would be to temporarily move one large file to another location such as an external USB drive to free up a chunk of free space, then use the tool to correctly remove other unwanted files before moving the first large file back again.  Ideally, the moved file should be not part of the file set for the task where you are using the clean up version tool if possible, i.e. a file for a different task while cleaning up files for a second task.  This is to avoid the metadata being updated to suggest the file is missing that has been moved! (Hope that makes some form of sense!).

Mahalo (Thanks) for the suggestion, Steve.  I deleted almost 1Tb of unneeded files from the backup disk and prepared to use the "Clean Up Versions" tool to remove the older backup versions.  When I started ATI, however, I got a message that there was an update that needed to be installed.  I dutifully installed the new version (ATI 2021 Build 34340), only to find that there is now no "Clean Up Versions" tool - and I can't find any other tool that will do the needed cleanup. 

So . . . now what? Is there any way to get rid of the old versions without messing up ATI's backup tracking system??

This may be a situation in which I need to submit a support Case to Acronis help, but that was a long messy process the last time I had to do it.  I'll appreciate your suggestions!

Aloha,

Tom in Kona, Hawaii Island

Tom, the clean up versions tool is still shown on my systems with ATI 2021 #34340 so should be there on yours too!

I would suggest trying a Windows restart initially to see if that brings back the option, or else do a Repair Install of the #34340 version as per KB 60915: Acronis True Image: repairing program settings

Aloha Tom Daniel, and Steve,

Sorry Tom, but misery loves company. :-)  Most importantly - Happy New Year! So long 2020.

My external backup drive filled up several times since I stopped posting to this thread. I tried an old trick, which worked for me years, and earlier versions ago, which was to change the number of old chains to keep for both my C drive (full), and all the other backups (differential). That didn't work.

At least now the cleanup tool is working properly, and it is showing all of the .tib files that are in each backup folder so I can clean up to a version that leaves fewer chains than the limit I set. As you might guess, that doesn't make it stop at the setting for max number of chains, and in a couple months I have to use it again.

Steve - I just read your opening response to Tom's post. I had to laugh, and cry. The tool that is invoked when the user's drive runs out of space has a problem when it tries to work on a drive low on space. WTF? Please tell me that was a joke. We're going to operate on your heart with a special tool created to work on your heart. However, it doesn't always work when you have a sick heart, which, is, of course when we would use it. Insert emoticon of head banging on wall. Preferably, the head of a developer.

Ok, back to our regularly scheduled programming. Thanks for your latest response Steve.

I've given up on getting Acronis to properly clean up. Is there anything a little less than an uninstall, and delete all the backups that is likely to make it work properly again? If not, I'll go nuclear, and risk Murphy's law. If I do the latter, how do I make sure that I'm using the absolutely latest .exe with which to do the install?

I have an older external drive that I should be able to move all of the backup files to before I wipe the current drive. If I do that Steve, and Murphy's law kicks in, will I be able to restore from the backups that I moved?

Thanks,
Dave

Unfortunately, the Acronis Clean up versions tool needs at least 250MB of free space in which to operate and fails when there is a lot less than this!  Not a joke for anyone in these forums!

If you move a file or files temporarily to create the necessary free space to all the tool to run, then move the same back again to their original location(s), all should be fine!  If you can move any non Acronis related files, probably better!

Happy New Year to you too Dave and all our other readers!!

Well, I must say this is an entertaining thread that reads like a good horror story.  From the user posts I believe it is clear that the TI task database is corrupted to the point that it will no longer function correctly.  So the dilemma for the user continues. 

I am of the opinion that the procedures outlined in KB 60915 are good suggestions however, they are lacking consideration of one critical factor that was introduced in TI 2020.  That factor is the introduction of backup tracking using metadata and the addition of a metadata database for that purpose.

As a consequence I am proposing a solution below that may well NOT solve this issue for anyone posting here but, one that I believe stands a better chance at success than that offered by the KB 60915 knowledge base.  I recognize that posters here may wish not to try this method however I ask you, what at this point do you have to loose?

My proposed Fix is outlined below:

1. Select the trouble task in app GUI then click on the Options button
2. Select the Backup Scheme tab
3. At the bottom of the window, select the Initial settings button
4. In the warning box that appears select Yes.  Your screen will blur while the change is made
5. Once the action completes change your Backup Scheme settings once again to your desired settings operation strategy
6. Once your settings are completed click on the Ok button
7. You should be returned to the normal GUI window at the Backup tab
8. Click the Back up now button to run the newly configured task
9. Monitor the backup Activity tab watching for the expected Clean up activity

The expected results of the steps above are:

• Step 3 above should reset the task to the default task settings that were present at the time of original task creation
• Step 5 will set the users desired task operation parameters
• Step 6 will change the default settings to the user preferred settings
• Step 8 will run the new task creating the next Scheduled backup task but more importantly will save the newly configured Backup Scheme settings

Keep us posted.

Steve,

250MB's is much smaller of an amount of free space than I imagined would make it throw up a hair ball. My backups fail when the free space drops below a hundred or so gigs.

You might have missed my question asking if there's a process one level below scorched Earth on the backup drive, and an uninstall/reinstall, then create the backups again from scratch, approach. If I do that, I won't be putting anything back as I don't want some remnant to muck it up, and make the bakups ignore the chain limits, like it's doing now.

Happy new year Steve. Best place for 2020 is the rear view mirror; too small to see.

Dave

Hi Enchantech,

Come for the name, stay for the advice. Is that the smoking medication that Ray Liotta is taking?

I was delighted to see such a well written post until I got to the instructions. Select the trouble task in app GUI... Ok, Would that be button, link, hypertext...? In any case, I'm looking at the GUI that is presented when I launch the app, and there is no "trouble task."  I'm running ATI 2020. Maybe that's the problem - it's 2020.

I'm not sure which problem the steps are supposed to address as we've discussed a few in this horror story thread. Is it to fix the cleanup tool, or to make the backup routines follow the chain limit settings? Ok, that was two.

I'll most likely be glad to give it a try once I know which problem the steps are supposed to fix, and where to find that pesky trouble task thing.

Thanks,
Dave

Sorry, the "trouble task" is meant to convey "the task you are having this problem with"  I could have written it better.

The instructions are to address the issue of the chain limits not being followed although it may fix the cleanup tool issue as well.

Enchantech,

Thanks for clarifying. I really appreciate the additional information about the expected results of the steps. That is exceptional. There's one thing about that, and it doesn't reduce at all my level of appreciation.

The steps of going back to the original settings, and then reapplying the current settings, is like telling someone to wash the dishes first, then dry them. They can't get that right, and sometimes reverse the order. So I tell them what I told them originally, just wash the dishes, and then immediately change my instructions back to wash then dry, and they miraculously now know how to do that properly. If my analogy is inaccurate, please let me know.

If my current settings are being ignored, misunderstood, or not implemented properly by the software, and so I go back to my original instructions, and then immediately back to the latest, and that works, well, that's as good a reason for a WTF as any other.

To be honest, I don't look for opportunities to criticize software, I don't need to. They shouldn't call it going postal. Going software user might be more appropriate.

I'll give it a try, and let you know. BTW - the chain issue is happening yo all of my backups, the two full, and the three differential.

Thanks,
Dave

Dave, one of the possible causes here that could be resolved by the suggestion from Enchantech is if you have set a value for free disk space at the top of the Notifications settings page for your backup tasks.

Example: If you have set a value as above, then try disabling this setting and try using the Clean up versions tool again for the same task.

David,

Like I said in my solution, I understand if a user does not want to give the solution a go.  I am glad that you are willing to give it a go.  Will the solution applied to one task fix others that are similarly broken?  I would think not.  I would think that if all tasks exhibit the same behavior then the fix would need to be applied to all tasks.

The idea of the fix is this, I think it is obvious that the task(s) database has become corrupted and in this case I believe that corruption exists in the backup tracking functions of the app. So if a return to default settings to the task(s) Scheme is applied my thinking is that now the task Scheme is back to square one.  So now if the settings are changed again the mechanism used to make the application apply and save those settings is to run the task creating a backup by clicking the Back up now button.  This should in my opinion, cause a rebuild of the backup file tracking data.

In Steve's suggestion above, I would think that going back to the original settings would not clear that entry and only reset the task Scheme.  I did test this out to a degree before I posted the suggested fix.  I found that the task I tested this on I had changed the Schedule of the task manually to Do not schedule in original configuration.  Clicking on the Initial settings button in the Scheme window did not change the Schedule.  So my assumption is that only the Scheme is changed by this method and the rest of the task settings remain intact.  Thus I believe the task will resume the Schedule that exists prior to applying the fix.  Having said that I have not tested that so it might not.

I can say that backup tracking in the application as it exists today was changed in the TI 2020 product.  Did this issue exist in the application prior to TI 2020?  Yes it did and the reason it did was due to users deleting or moving backups using Explorer rather than the TI app.  Why did using Explorer cause the issue?  Using Explorer broke the tracking of the backup task files which corrupted the task database.  If database corruption is the fault that causes the issue then why would my fix be the answer?  My solution is focused on what I believe to be the mechanism used for backup file tracking now in place since TI 2020 which is metadata which I believe is now maintained in a separate database apart from the task database. 

What I believe will take place for a user applying my fix is this.  Once a return to default Scheme is applied, that action will reset or clear the metadata that exists for file tracking.  When the user then changes the Scheme again and runs the task, metadata will be rebuilt for the task and applied to all backup files of the task and fix the issue.  Why do I think that is true?  Because since the release of TI 2020 it has been possible to change the Scheduling and Scheme of a task in the application and have those changes work.  Prior to TI 2020 this was not the case and users having a corrupted task database had the choice of changing the task database file naming to .bak and allowing the app to replace the file and hope that in that process the corruption would be cleared.  If that failed the solution was to delete the task and then recreate the task again using a new task name and destination folder for the backup files.  One of the goals in changing the backup file tracking in TI 2020 was to address those solutions into something more easily applied. 

Hi Enchantech,

Thanks for the thorough follow up. It's well beyond what I would have expected, or have been likely to receive, if I were dealing with top level Acronis support.

I agree with your theory about the database, and the impact of reseting to default. However, the code should never assume a reset of the metadata just because I default the settings. From a programming standpoint it is a ridiculously bad idea to have the app forget about all the prior archives because of a change in settings.  A high school student would fail their programming course if they did that.

How many years ago was it that the developers learned that people were deleting extraneous archives with Explorer? Ten maybe? Would it be safe to assume that the users were doing so because the chain limitation setting wasn't working that long ago? I would think so.

A team of developers concerned for the customer's experience would have done a deep dive into the code to rectify the problem, and eliminated the need for users to use explorer to delete archives, with the attendant impact on the database. Or at the least thrown in some code that would have noticed the absence of an expected version chain, and dealt with that in an intuitive way for the user. I don't do this for a living, and yet the answers appear painfully obvious. I rant, because I love.

I'll give it a try, and let you know. Thanks again.

Dave

BTW - the site logged me off before I clicked save because I took a couple days to write it. It then told me that my access was denied, blowing out my text. Fortunately, I learned a long time ago to copy text before hitting submit, and didn't lose all of it. Couldn't the Web dev anticipate this? It never ceases to amaze me how often I'm deeply impressed by what software does, and in the next breath see the product of disregard, and ignorance.

David Vallee said:

I agree with your theory about the database, and the impact of reseting to default. However, the code should never assume a reset of the metadata just because I default the settings. From a programming standpoint it is a ridiculously bad idea to have the app forget about all the prior archives because of a change in settings.

You misunderstand here.  The product does not forget about all prior archives because of a settings change.  What takes place is the archives settings are reset to the default task Scheme.  The result is that the archives assume the default task setting on a global basis for the existing backup chain.

After you reset to default and then subsequent to that you modify the Scheme again, that scheme will be applied to the archives when you commit this change by clicking the Back up now button on a global basis for exiting backup chain.  This action effectively changes all settings anew for the task therefore, this fixes the issue.

Enchantech,

Thanks for straightening me out.

I don't quite follow if these steps will affect the backup in which I default the settings, then change them to what I prefer, then click backup now, or have, as you wrote, a global effect?

Also, I can't find the button to "default the settings" of any of the backups. Clicking on the drop down arrow gives me a list of items, none of which are default settings. I attached a screen shot if that helps.

Thanks,
Dave

David,

You wrote: I don't quite follow if these steps will affect the backup in which I default the settings, then change them to what I prefer, then click backup now, or have, as you wrote, a global effect?

The steps I outlined for you will:

1. Only affect the backup task that you desire to default the settings
2. After the default settings are restored the next step is to change those defaults to your preferred settings.  After entering your preferred settings clicking the Ok button will commit those settings and return you to the Backup GUI window where you will see the Back up now button.  Even though your settings choices have been committed the application will not save those changes until you click the Back up now button and run the task.
3. The global effect I speak of is a reference to all of the existing backup files you have for this task.  In other words the steps outlined will be applied to all of the backup files that exist in the backup chain.

Looking at the screenshot you posted have a look at the bottom left corner of the windows and you will see a button named Initial Settings.  That button is the one that returns the task settings to default values.

Hi Enchantek,

Thanks for the follow up.

Why would I have not determined that initial was synonymous with default? Maybe it's the fact that they don't, either in plain English, or the lexicon of software, mean the same thing. So why would I expect developers who spend their lives in software know that? Silly me.

Why doesn't a group of people storm the offices of companies that make software, like they did the capitol? Yeah, I'm kidding.

It's truly sad that in 2021 we still need forums like this because these assholes can't make software reliable enough that we don't need to help each other like this. Could you imagine any other industry lasting for more than a few weeks who did shit like this? And these fuckers make billions of dollars. It's enough to make anyone go postal.

Thanks again. I'll let you know how it works out.

Hi All,

It appears that our combined efforts to figure out why Acronis' software doesn't work properly has resolved my issues. I appreciate everyone's input.

I still cannot get my head beyond the concept that we, the people who paid for this software, are the ones who need to support each other. Imagine a car manufacturer, plumbing company, nuclear power plant control software manufacturer that creates a forum for people who have trouble stopping a power plant from melting down, a car from losing their brakes, or ability to turn, or a home owner having to find people to help them turn off their water.

I am currently uninstalling battle.net, and call of duty software, which is a multi-billion dollar company because they can't get their fucking software working properly because they bloated it with code to tie together their platforms, and sell more shit. This is fucking outrageous, and should be the target of a class action law suit.

David Vallee said:

It appears that our combined efforts to figure out why Acronis' software doesn't work properly has resolved my issues. I appreciate everyone's input.

That's good to hear, thanks for confirming.