Skip to main content

ATI 2020 Differential Files Deleted

Thread needs solution
Forum Member
Posts: 14
Comments: 40

I’m using the Windows version of ATI 2020, and ATI is at version 25.1.10.22510.  I have differential full disk backups set to do a full backup then 6 differentials before doing the next full backup.  Automatic cleanup is set to keep 4 version chains.  I backup to a Synology NAS using WiFi.  Last night during a full backup my PC's wireless adapter reset itself about 2 hours and 20 minutes into the backup causing the backup to fail, and I was unaware of the failure until this morning.

This morning Excel wasn’t responding and other things weren’t working, so I rebooted.  After the reboot ATI started the full backup again, and this time completed fine.  When I checked the backup folder, I noticed all the .tibx files, 13 of them, were gone except the one created this morning and the 12K tibx file.  I looked at the log and found messages for all of the deletes for the tibx files, but no error messages that would cause the tibx file deletions.

Because this is the first time I’ve used the differential backup method maybe there is an error in the options or maybe the error from the previous night triggered the deletions.  When I did forum searches I didn’t find anything similar to this problem.  Does anyone have an idea why the deletions occurred?  I’ve attached the logs from last night and today in case they are of any help.  Thanks for any help you can provide.

0 Users found this helpful
Legend
Posts: 83
Comments: 19765

#1

Gary, the second backup_worker log confirms the deletion of all your previous .tibx files from ASUS Differential-0013.tibx to the first file then the initial file truncated to 12KB.

It doesn't explain why this cleanup happened given the cleanup rules you say are set to keep 4 backup version chains.

I would suggest opening a Support Case direct with Acronis for this issue and submit an Acronis System Report to them for investigation to see why all your backup files were deleted when they should not have been?

Forum Hero
Posts: 68
Comments: 8281

#2

Gary, could you also screenshot your backup scheme info for reference without making any modifications to it. For example here's mine from 2019.  Just want to see what your retention and cleanup is actually set to.

Example:

 

Forum Member
Posts: 14
Comments: 40

#3

Sorry I missed your reply.  Attached is a screenprint of the Backup Scheme window.

I opened a ticket with support on Monday and sent logs and System Report.

 

Attachment Size
530852-179896.jpg 440.56 KB
Forum Member
Posts: 14
Comments: 40

#4

I thought I'd provide an update on this issue.  The last email from support said to create a new backup and not use auto cleanup.  I had to copy and paste the backup_worker log messages that showed the deletions of the backup files and the error id because he gave no indication that he looked at the logs,  He kept asking for a screenshot of the error.  I told him one didn't exist, and it was a one time failure.  Because there was no screenshot of an error it seemed like he didn't know what to do.  He seemed more concerned that the current backup files were good rather than finding the cause of the problem.

The good news is that the differential backups have been running fine since Feb 24 and auto cleanup deleted a version chain when it was supposed to do it.

Forum Star
Posts: 148
Comments: 1023

#5
GaryG45 wrote:

...The last email from support said to create a new backup and not use auto cleanup.  ...

The good news is that the differential backups have been running fine since Feb 24 and auto cleanup deleted a version chain when it was supposed to do it.

The comment from support is a bit unsettling.  I wonder if that  "not use auto cleanup" was the 1st level support not knowing what else to suggest, or those that really know saying there is a bug and auto cleanup has a problem.  (It obviously has a problem somewhere or your original backups would not have been deleted.)

Hopefully, auto cleanup (mostly) works and you will have no more problems.

I vaguely recall there have been other reports of odd cleanup happening during restart of failed backups but I don't remember any details.  (Actually, I vaguely remember it happening to me.  During a restarted backup, a chain was deleted even though an Incr backup, rather than full, was being taken.  BUt that was a long time ago and may have been on ATI 2019.)

Forum Hero
Posts: 36
Comments: 7656

#6

GaryG45 wrote:

The good news is that the differential backups have been running fine since Feb 24 and auto cleanup deleted a version chain when it was supposed to do it.

I use a differential scheme for a backup of a secondary data disk on my main PC which I use everyday.  This secondary disk hosts my User folders in Windows 10 including the Default user. I have only one user account defined on this PC.

I too have not used a differential scheme in the past but wanted to try it out.  So I setup a differential backup using default settings of the TI 2020 app.  This means that my Backup Scheme is a Differential scheme and the Method is Differential.  The Schedule chosen is a Daily backup, Once a day, at 9:00AM.  By default the cleanup rule is a Full disk version followed by 5 differentials for 6 months.

This task was configured on Nov. 28, 2019 as a bit of an experiment using a default Differential scheme.  The initial size of the data on disk at the time of task creation was 39.4GB.  That compressed using Normal compression to 12.8GB.  Since the start of the task the space on my storage device for this task grew to 312.1GB.  I had planned today to run a Manual cleanup of the storage location of the task to redeem the space used.  The cleanup took approximately 7 minutes over a networked Gig connection at 830 Megabytes per second average.

Tomorrow after my next Full version runs, I will change the Schedule of this task to more mimic what you have in place so that versions do not grow as has been the case so far.

My point here is to say that I have not experienced any issues with the differential task in scheme or schedule.  I would suggest to you that what you have experienced is normal and that it just so happened that the circumstances of your experience occurred at the precise time that scheduled automatic cleanup as defined by the task was set to run.  Given your network had issue this caused the task to abort and then rerun once you fired up your PC again and at that point the task completed and all is well.  I fully expect this to be the case in my situation and if it proves not to be I will post again here saying so.

I am glad to hear that currently, all is well with your task. :)

Forum Member
Posts: 14
Comments: 40

#7

@Enchantech thanks for your information.  My auto cleanup was not scheduled to run when I had the error.  The full backup that ran on Feb 24 was starting the third version chain and because I'm keeping 4 version chains it shouldn't have run until the fifth version chain started.  This past Sunday my fifth version chain was started and auto cleanup worked fine.

My theory is that the network error experienced the night of Feb 23 set a flag making ATI think all previous backups were corrupt or invalid.  On Feb 24 after the full backup was successful ATI deleted what it believed were the corrupted backups.

Forum Hero
Posts: 36
Comments: 7656

#8

I agree with your thought that the backups were deemed corrupt by the application and thus cleanup was triggered given your scheduled cleanup was not scheduled to run.

TI uses a new technology called CBT (Changed Block Technology) which could be the reason for what you experienced.  An excerpt from the user guide on CBT appears below:

Changed Block Tracker (CBT)

The CBT technology accelerates the backup process when creating local incremental or differential disk-level backup versions. Changes to the disk content are continuously tracked at the block level. When a backup starts, the changes can be immediately saved to the backup.

A drop in network connectivity could have corrupted the metadata used by the app for data tracking purposes which introduced corruption and in turn triggered the backup to save the Block Tracking to the backup and discarding the rest.

Again, glad to know that your task is functioning as it is suppose to now.