Salta al contenuto principale

Unexpected change from tib to tibx format

Thread needs solution

According to the FAQ, "Backups that were originally created with a pre-2020 version of the software, and continued with the version 2020" will continue to use the tib format.

I have 6 systems with v2020 and all were installed over previous 2019 versions and are running existing backups. On 5 of them, as advertised, the backups are still using tib.

But on one system, all 3 of my full-disk backups (identical except going to different destinations) have started creating tibx backups. I can't see any reason for the change. There's nothing unique to this system compared to the other 5. All of these backups are going to local drives or my NAS ... no cloud stuff going on.

I haven't worked with tibx files yet, so I don't have any format preference at this point. But it would be nice if all of my systems were using the same format. What caused this system to switch to tibx and is there a way to forcefully bump a tibx to a tib and vice-versa?

0 Users found this helpful

David, welcome to these public User Forums.

This sounds like you have hit the issue described in KB 63613: Acronis True Image: local backups are not available for recovery if "metadata" file appears in the backup destination - if you see metadata file(s).

The above issue will give the symptoms that you describe with an older backup task going from .tib files to creating .tibx files.

Thanks for the reply, Steve, but I do not have nor have ever seen any "metadata" files in any of the destinations that these backups write to.  The KB article cites this as the key indicator, and the solution involves looking for the date of the metadata file.  So I don't think this is applicable.

These are all full backups.  I haven't had need of any full restores, but all of the files, both the newer tibx files and the older tib files, seem to be fully functional.  

On a related note, how do I disable the online dashboard altogether?  I also suffered through losses of notifications for all of my backups, as described in other messages, and I don't like Acronis' servers screwing around with my backups.

David, can you post either a listing of how your files look or a screen shot of the same?

The only way to disable the online dashboard is to stop and set the Acronis Managed Machine Mini Service to disabled start up but this does not remove existing information from the dashboard - that has to be done manually, one by one.  Note: the computer needs to be either disconnected or powered off for associated backups shown in the dashboard to be removed.

Thanks again for the reply, Steve.

12/01/2019  02:03 AM   102,537,326,592 ArcturusCLocInt-0001.tibx
11/29/2019  03:28 AM   102,286,204,928 ArcturusCLocInt.tibx
11/15/2019  03:30 AM   127,829,574,656 ArcturusCLocInt_full_b421_s1_v1.tib

All the other destinations look the same, with varying numbers of older backups.  On this system - which again is the only one that has this issue - when I look at Backups - Activity, only the two tibx backups are shown.  If I go to Recovery, again only the two tibx backups are offered.  On my other systems, all the tib backups are shown under activity and restore.

One mystery is why there's no backup on 11/22.  There should have been one, and the other backups on this machine (to different locations) are all missing a weekly backup.  I didn't notice it at the time because the notifications had been zapped out.  I've found these backup logs and they show routine notes ending with "Operation has succeeded" and showing the backup locations.  But these files are not out there.  What the hell is going on?

BTW, should I be concerned because the tibx is much smaller than the tib?

I disabled the AMMMS service on one machine.  The service has the unhelpful description "Enables data of true image on the machine".  Anyway, that system shows offline on the online dashboard.  It's scheduled for a backup tonight, so I'll make sure it goes ok before removing the backups on-line.  Are there any undesired side-effects from disabling that service?

And as long as I'm ranting about Acronis, I had Active Protection turned off on all my systems with 2019.  I have other software doing that sort of stuff.  The 2020 upgrade turned it on for all of them without asking or notifying.  I noticed that local disk-to-disk file copies were running about 90% slower than expected on my main system, which led me to find this nonsense.

 

David, thanks for the details of the file names.  This clearly shows that your backup task has changed from creating .tib files to using the new .tibx format and naming conventions.

At this point in time, if you still had the most recent ArcturusCLocInt_full_b421_s1_v1.tib file, then I would suggest that you remove the task settings from the main ATI GUI then use the option to 'Add existing backup' selecting that .tib file to add back the older format task.  However, from your comments, it seems that that is not an option as the .tib file(s) have disappeared.

The only other option that I can suggest would be to take a read of forum topic: How to create a Disk backup as .tib (not .tibx) which I posted back in September and see if this will work for you in creating a new backup task using the older .tib format?

With regards to the file sizes, difficult to know whether the smaller size is an indication of an issue or just a consequence of differences in Exclusions for the .tibx backup task caused by task settings being reset by the MMMS server issue!

All upgrades to new builds or versions of ATI will cause all the default features of ATI to be re-enabled again, including such as AAP.  This caught me out when I upgraded to 22510 by re-enabling the MMMS service which then reset all my backup settings again!  This is 'normal' behaviour for many applications not just Acronis.  Even Windows 10 has done this to me on some of the recent upgrades for some of the settings that I automatically change!

Steve, I'm trying out your method now.  But your kb article says to look for all occurrences of ".tibx" and replace with ".tib" (with the period in front).  You need to look for "tibx" and replace with "tib" (no period).

In my .tib.tis file, the are two places that are pertinent ... One is under <archive options ... format="tibx" and the other is under <stream options ... format="tibx".  The only ".tibx" reference is under the <volumes locations> section and that just controls the output filename.  If you only do the 3rd one and don't do the first 2, you end up with what appears to be a tibx format file that just has a tib file extension.

I also have a reference to "*.tibx" under the exclusions listing but that needs to be left alone.

Still uneasy about the file sizes.  I've done no customizing on the exclusions list, and I don't see any significant differences between the list on my problem system and the others.

Also, if switching between backup formats is as simple as changing three items in the xml file, then why isn't this selection available from the GUI?

 

David, if using find & replace, then yes, just use tibx for the search and tib for the replace, but ignoring the entry in the exclusions list.

It would be an easy option for Acronis to offer this in the GUI but they haven't and don't seem to be inclined to suggest that users could have this option.  I suspect that they want to move in line with how their premium business Acronis Cyber Backup product works in using .tibx and simplify the coding stream for one used by both applications.

Steve, have you tried converting an existing tibx backup (i.e., one that has already been run as a tibx) to tib with the same approach?  Seems like it might work.  But Acronis modifies the tib.tis file after each backup is run, and I've got to do some testing to see what it is that gets changed and whether the changes would screw this method up.  If it works, it would be a reasonably simple method for me to get everything back to tib on this system.

The Acronis faq doesn't list any advantages of the tibx format.  In fact, it shows some limitations, like the inability to mount tibx files.  If you're not doing cloud backups, have you seen any reason to want to go to tibx?

I need to get to know the tib.tis file better.  When my notifications got zapped last week, it would have been much faster to cut-and-paste the <notify> section of the tib.tis files.

There is another reference to "tib" in a tibx backup file.  All my tbix script files have, near the top, 

<reserve_backup_copy format="tib" need_reserve_backup_copy="false">
                    <volume_location partition_id="" uri="" volume_id="0" />
                </reserve_backup_copy>

Any idea what this is about?

And thanks for all the replies on this.  I haven't gotten any answers on how and why all this silly stuff is happening, ( :-) ) but I'm learning a lot.

David, I don't believe that you can convert from an existing .tibx file back to .tib - there are many other changes happening under the covers, so all that my method is doing is to simulate having a task which came from ATI 2019 instead of being created by ATI 2020.

ATI 2020 is designed to continue running older tasks from 2019 or earlier as .tib but there is no guarantee that this will still happen with future versions of ATI such as 2021 etc.

The main reason for going with .tibx backup files is that it is bringing ATI in line with the Acronis Cyber Backup / Backup 12.5 business applications file formats and may allow further convergence between these products in the future.  AFAIK the business products do offer the functionality that is currently missing in ATI 2020 such as mounting .tibx files etc.

From a business perspective it is reasonable that Acronis would want to streamline their applications to use a shared code base rather than having to maintain two different coding streams, perhaps with an eye on a future where ATI becomes a 'Lite' version of the business application with the features wanted by Home & Small Business users, and a direct upgrade path to advanced features needed by larger Enterprise business users with Server products etc.

The reference to tib format for the backup reserve copy section of the script file is another example of changes coming in with ATI 2020, as that section is not used for .tibx tasks which do not offer an option for this on the Options >> Advanced settings page.  This is only used for older .tib tasks which still have this option.

With ATI 2020, an option for Replication is now being offered, albeit only to the Acronis Cloud, where this is the replacement for the old 'Backup reserve copy'.  Replication at this point is not very useful unless you have high speed upload speeds and lots of Cloud storage available - this is because if is simply copying & uploading the local .tibx files and version chains.  So if you have a backup scheme that creates a new Full backup after 5 incrementals, this is what is being uploaded to the Cloud.  Personally after giving this a try, I found my computer was continually uploading to the Cloud and repeating the upload of full versions etc, such that I had to kill the task.  If this gets offered for replication to local or network drives, then it would be much more useful.

Thanks again, Steve.  I really wouldn't mind bumping all the other systems to tibx.  I just don't care for having one system using the new format while the other systems are using the old.  There's obviously a way to convert a tib backup to tibx - since it did it on my one system for reasons unknown - but I can't find anything in the docs about how to do it, or how to force it to get done through indirect means.

I did go back into a backup from early November and fetch the scripts directory to compare the files.  The tibx versions do have more exclusions in the users\appdata tree, but one of these account for the large reduction in size that I'm seeing for the tibx archives.  Do you know if they changed the compression with 2020?  If not, I'll start a support case to get some answers on the archive size.

 

David, there was no mention of any changes related to either exclusions or compression for when ATI 2020 was introduced as a Beta product for testing, and none that I have seen since.

It may just be that ATI 2020 is better at deduplication when using .tibx files than it was in the earlier versions using .tib files.  Not sure I like these new words but this is something again brought in from the premium business products and may also account for extra processing time during backups in order to identify all duplicate files and only keep a single copy of each but place a marker for where a duplicate was found etc?  Most computer systems tend to have a whole raft of duplicate files and there are commercial applications available to help identify and remove / reduce these, so if this is what ATI is doing, then that is another 'bonus' feature!

Concur with Steve on the above.  TI 2020 uses features of the deduplication process namely block tracking to achieve higher levels of efficiency thus reduced backup size and increased performance.

So I gather that this improved deduplication process is only used in the tibx format.

I just ran a new tibx backup on another system and got about the same reduction in archive size compared to the tib backup.  The tibx archive is about 80% of the size of the tib.  Are you seeing similar reductions?

Everything I've read about deduplication (not very much) is about corporate computers backing up to a common datacenter/cloud in which the duplicate data exists on multiple computers.  For individual computers creating separate archives, I guess the same technology would apply, but is a 20% reduction typical?

One other mystery.  The notification message I got from my newly created .tibx backup is ...

2019-12-07T15:10:27:987-05:00 10392 I00000000: -----
2019-12-07T15:10:27:987-05:00 10392 I00000000: ATI Demon started. Version: 24.5.1.22510.
2019-12-07T15:10:28:112-05:00 10392 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false; 
2019-12-07T15:10:28:112-05:00 10392 I00640002: Operation Deneb started manually.
2019-12-07T15:10:28:190-05:00 10392 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false; 
2019-12-07T15:10:28:190-05:00 10392 I013C0000: Operation: Backup
2019-12-07T15:10:28:190-05:00 10392 I0064000B: Priority changed to Low.
2019-12-07T15:45:55:057-05:00 10392 I013C0006: Operation has succeeded.

"format tib"?  And why are these logs so sparse for .tibx backups?  The old .tib logs were maybe too verbose, but at least it gave the destination of the archive.  This .tibx log doesn't tell me much at all.

 

Backup reserve copy attributes: format tib; need_reserve_backup_copy false; 

The above line only refers to older format .tib backups where there was an Advanced option to create a Backup reserve copy (full backup only), but this is no longer offered for .tibx backup tasks as is replaced (partially) by the new Replication feature which only goes to the Cloud.

The log file content from the email notifications comes from the ti_demon logs but these have been abbreviated in ATI 2020 to just contain key points about the backup task operation.  All of the detailed and diagnostic log data is now moved to the backup_worker log files but not shown to the end users.

Backup file sizes are dramatically reduced with the .tibx format.  Depending on type of backup file (Full, Inc, Diff) will determine efficiency of reduction with Inc being the largest.

Thanks for all the responses.  I guess it's obvious that I'm a bit ambivalent about 2020.  I started using Acronis about the time they hit the market and incorporated it in a business network as well.  But now as a home user with a redundant NAS and plenty of disk drives, I have zero interest in cloud functions.  The notion that someone could possibly get into my on-line Acronis account and launch a restore operation on one of my systems scares the hell out of me.  And this snafu with notification settings and the issue that started this thread only made me more wary.

My concern is that the rush toward cloud-based solutions may reduce the functionality for local-based backups.  The inability to mount tibx archives is an example.  The inability to select which type of format in the GUI is inexcusable.  If mounting archives was essential to my operation, and with no way to create new tib backups - other than Steve's method - I'd be looking for a new solution.

The tibx format may be a great technology, but it seems to me that they've rolled it out, and forced users into it, before they had all the needed features ready.