Is there an explaination as to why the backup files were changed to .tibx.
What are the advantages, new features etc. What does the new format do that the old could not?
WonderWrench,
In addition to the articles linked to by Steve the .tibx format offers deduplication which further reduces backup file size by not backing up duplicate data, this helps in performance of the app as well however, you will notice an increase in backup times at first use of the product due to data processing necessary to accomplish this.
Reliability has been improved with the new format as well via an enhanced method of validation. Many users have complaints about the speed of the new product but I attribute that to learning curve pains.
The .tibx format was introduced in the Acronis Backup 12.5 product, a business class product, and so the features above are possible now to the consumer product with the introduction of .tibx to True Image.
I would expect to see additional capabilities added to the True Image product that the .tibx format supports now in Backup 12.5 going forward.
Enchantech wrote:
Reliability has been improved with the new format as well via an enhanced method of validation. Many users have complaints about the speed of the new product but I attribute that to learning curve pains.
I find it very questionable that the validation history of Ati has been changed. The result can be seen now "Extended backup times" and the hit it "Validating brings you nothing actually". Or do I see that wrong here?
I find it very questionable that the validation history of Ati has been changed. The result can be seen now "Extended backup times" and the hit it "Validating brings you nothing actually". Or do I see that wrong here?
The .tibx format used in TI 2020 is much different in data handling than was present in the previous .tib format.
As I am sure you have read the .tibx format is used in Acronis Business product Backup 12.5. Validation of this format is designed specifically to detect corruption in backups. This is achieved by checksum calculation of every data block saved in the backup with the exception of file level backups located in the Cloud. The later are validated by checking consistency of the meta information saved in the backup.
The end result is a reliable method of checking for corruption of a backup. See the information below which was extracted from the Backup 12.5 documentation covering Validation:
Backup validation
This option defines whether to validate a backup to ensure that the backup is not corrupted, before data is recovered from it.
The preset is: Disabled.
Validation calculates a checksum for every data block saved in the backup. The only exception is validation of file-level backups that are located in the cloud storage. These backups are validated by checking consistency of the meta information saved in the backup.
Validation is a time-consuming process, even for an incremental or differential backup, which are small in size. This is because the operation validates not only the data physically contained in the backup, but all of the data recoverable by selecting the backup. This requires access to previously created backups.
Taking this into consideration users must understand that Validation should be selected upon a desire to determine that a backup is not corrupted prior to the recovery of such backup. Additionally, depending upon the complexity of the backup itself, validation may take considerable time. This is what I mean when I say that there is a learning curve with this new backup format.