Skip to main content

*Name*.tibx; *Name*-0001.tibx with same content (back-ups "inside") - Why?

Thread solved

Hello all, we got a new computer this year, so I bought and installed the new Acronis 2020 version. Before we had a rather old version of Acronis.

I realize that - with the new version - the names of the back-ups have changed, so it is no longer possible to see right away which back-up is a full one and which an incremental back-up - so far so (not so) good, but I'm getting used to that.

What confuses me a bit is the following: I did the first back-up on 9 Sept and changed the settings to do a back-up every 2 days and to do a new full back-up after 5 incremental back-ups. This worked fine.

But now I have 2 files: *Name*.tibx and - after the first new full back-up there is a second *tibx-file, that's called *name*-0001.tibx.

This would make sense to me IF the first *.tibx file contained the first full back-up and the following 5 incremental back-ups and the 0001-back-up contained the second full back-up and the following incremental back-ups.

BUT - when I look at those back-ups - they contain both the exact same files???

I attached two pics, so you can see what I mean.

Since both files have almost the same size, this also worries me because it might fill up my hard disk faster? Can someone explain this to me? This would be great - thanks.

PS: Sorry if I haven't expressed everything correctly, English is not my first language.

Attachment Size
0001Tibx.jpg 61.7 KB
Tibx.jpg 58.32 KB
0 Users found this helpful

Sunny, welcome to these public User Forums.

ATI 2020 uses a different approach in how it uses the backup .tibx files depending on the type of backup being created.

For full backups with associated incremental backup files, there is now only one .tibx file which contains these within a single container instead of having multiple files with _full_ & _inc_ in the file extensions.  When a new backup chain is created, this will show with a 000?.tibx name.

For full backups with associated differential backup files, you will see an initial small (12kb size) .tibx followed by separate 000?.tibx files for each differential backup image, but where each file will show the same contents if double-clicked, including the 12kb file.

There should be no real difference in the disk space required for these backup files if the correct configuration has been selected for the backup scheme, i.e. the number of files to create, number of chains to keep, automatic cleanup etc.

Sunny, it looks like what the Explorer interface is doing is showing you all the backup dates for the backup task which are in the two files together. With the .tibx format, it seems as though the files cannot be looked at as discreet, separate entities.

Even when automatic cleanup is on, the original .tibx file for the task will always remain although reduced in size (to about 12KB). Whenever a new .tibx is created in a task, you will see that the date and time of the prior .tibx is changed to the time of the new .tibx, indicating that there is some linkage between them.

All,

The observed behavior of Bruno in this use case discussion are the effects of the utilization of metadata in backup file creation and the efficiencies that brings to the product when creating backup files. 

Thanks for your replies.

I will take a closer look at those files again tomorrow.  I guess I will have to change the automatic cleanup plan. Right now it is set to 150 days, but I think this is way too long. I will change it to a certain number of chains (probably 4) and see what happens.

Edit: Checked those files again today and added up the required/used diskspace and it is in fact not "doubled". So each chain shows *all* past, respectively all new back-ups, but they don't really take up any space.

So all is well, albeit being a bit confusing after all ;).

Sunny wrote:

So all is well, albeit being a bit confusing after all ;).

Glad all is well. I think it is confusing to all of us. 

BrunoC wrote:
Sunny wrote:

So all is well, albeit being a bit confusing after all ;).

Glad all is well. I think it is confusing to all of us. 

Definitly takes a while to get a hang of it.

Ian