Skip to main content

ACPHO - deleting old backup files

Thread needs solution

I've recently upgraded to ACPHO, before that I'd only just upgraded to ATI 2021 (from ATI 2020). I was backing up my PC using tib files but as I've upgraded I thought I'd try a brand new backup task (to use tibx files). Anyway, I set my backup to create a new full version every 5 incremental versions and to delete version chains older than 7 days and started to use the new backup task. First off that backup created a file in the form <backup name>.tibx and incrementally updated that file. Then it created a new a new file in the form <backup name>-0001.tibx and started incrementally updating that. I was expecting the old backup to be removed but this hasn't happened. The new and latest backup file has a modified date of 26 Sept but the previous backup file has a modified date of 12 Sept which is more than the 7 days specified for removal. I thought would this mean that the old backup file would be deleted but it seems I was wrong. I don't want a load of old backup files hanging around and I thought ACPHO would get rid of them for me. Can anyone explain to me exactly what should be happening here?

0 Users found this helpful

Robert, it's unclear what you have here. It sounds like a new .tibx file should be created every 6 days, assuming this is a daily backup. The very first .tibx file (<backup name>.tibx) will never be removed but it will be left at 12K size. Do not delete this file as it is critical to the chain.

It is recommended to use the number of chains rather than days under the automatic cleanup rules to delete older chains. It tends to be clearer and easier.

Hi BrunoC,

many thanks for your reply. I only do a backup once a week. I thought that the first option (i.e. create a new full version every 5 incremental versions) would create a new full backup file after 5 incremental backups. This used to be the case with my old backup task which created .tib files. The second option (i.e. delete version chains older than 7 days) I thought ACPHO would delete the old tibx backup file after all 5 incremental versions had been created (when it was older that 7 days) and when a new tibx backup file had been created.

Under the old scheme with tib backup files new individual tib files were created for each backup upto the required number of incremental backups, then a new 'full' tib backup file was created (for a new chain). The old chain (and all of its files) were deleted after they were older than 7 days.

I don't know what's happening with the new tibx scheme.

With .tibx files, the incremental updates are put into the same .tibx file with the full. For differentials, it generates new files. Every time a new file is created, the prior file is linked to it within the chain. Therefore, .tibx files should never be deleted outside of the Acronis UI.

Here is a FAQ about the .tibx format.

https://kb.acronis.com/node/63498

Also, Steve Smith often posts a list of various KB articles to read about .tibx to fully understand them. Maybe he'll post it here for you.

Hi BrunoC,

many thanks for your reply. I think I understand the tibx file scheme a bit better now. However, your recommendation of using the number of chains rather than days under the automatic cleanup rules to delete older chains - do you have a link that explains that in detail? I'm afraid I couldn't find any info about it.

Robert, the key point about automatic cleanup rules is that they are only applied after a new full backup has been created but there is a significant difference between the two options.

If you use 'Store no more than X recent versions / version chains' then automatic cleanup is performed as soon as the X+1 new full backup has been created.

If you use 'Delete versions / version chains older than X days' then those X days only start counting from the day when the new full backup has been created (so more files may continue to be created before anything is deleted!).

Per Bruno's comment above:

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,

many thanks for your reply. I've looked through the documentation links you sent but I'm afraid I'm still a bit confused. Does ACPHO always retain the original <backup name>.tibx file and what happens to the <backup name>-0001.tibx file when a new 'full' backup is created? Is it replaced with a <backup name>-0002.tibx file? If if it is replaced with a <backup name>-0002.tibx file then what happens when ACPHO gets to <backup name>-9999.tibx (I know that's unlikely to happen in my lifetime but I was just wondering).

Robert, with the new .tibx file format being used for all new Disk backups, the original .tibx file is truncated to just 12KB as new backup files / chains are created.  The 12KB .tibx file contains important metadata used by all subsequent files and the task.

Subsequent backups use the same root name from the task definition but have -nnnn numeric suffix added.  I would assume that the programmers have considered how to handle -9999 being reached and either start over again with -0001 or else use an extra suffix to the name to deal with that scenario.  I have never gotten out of double digits for my own backups using .tibx files so far!

Hi Steve,

many thanks for your reply. I guess that solves my backup query although I'm not sure why ACPHO would want to keep metadata used by subsequent files in the original file. Wouldn't it be better (possibly more secure) if all necessary data were self-contained in the 'current' backup file. Anyway, that's not my call.

Thanks again, for your help.