Skip to main content

Incremental File Names

Thread needs solution

Am I doing something wrong? I just upgraded from TI2019 to TI2021 and I always do incremental backups. I set up an incremental backup with 5 backups before doing another full. The file name that was created was MYBACKUP.TIBX. since I only backup all partitions on the C drive. I have other internal drives but I don't back them up. I noticed on my TI2019 my incremental backup name was MYBACKUP_FULL_B4_S1_V1.TIB. Then it could create an S2 then S3 and S4 and so on. But this TI2021 looks like it creates one file and then the second incremental adds to the first backup file making it bigger. Am I doing something wrong?  I was under the impression that the new verification process, letting you verify just the last created file, was going to speed up the process because the other incremental backup files were smaller than the first full backup. Am I wrong about this too? My goal was to speed up the verification process with this new TI2021. 

0 Users found this helpful

OK, I got information here about the file names ( https://kb.acronis.com/content/63516) but I would like to know about the validate the latest deverse backup version only. This doesn't seem to work. It validates the entire drive every time.

Mark, there has been lots of discussion in the forum about the validate of the latest diverse backup version - the official description is given in the ATI 2021 User Guide here:

Per the guide, this should validate only the last backup slice which equates to the last incremental backup.

In reality, validating only that one slice does not confirm that the backup is either valid or could be used for a successful recovery, as a validation would be needed of all incremental slices along with the initial full backup for this task in order to get a better indication of the integrity of the backup archive.

Having said the above, validation actually does nothing more than confirm that the data remains unchanged from the time when it was written to disk and a checksum added to the file by the process of recalculating the checksum.  There are potentially hundreds of checksum values which are written regularly throughout the file.

The issue with validation is that there is no guarantee that good data was captured in the backup archive - if the source data was already corrupted, damaged etc, or if there are any hardware issues latent - then the backup may be validated but be useless!  The only real method of confirming the integrity of the data for recovery purposes is to either recover it to another disk, or else use the options to convert the backup archive to a virtual disk format and boot the PC from that virtual disk etc.

Glad to hear from you again Steve!  Thanks for your quick response. You kinda let the air out of my validation balloon with those last two paragraphs.  I always depend on a good validation to assure I have data for a successful restore. I never had a restore fail on me and I do a lot of system building which causes a lot of backups and restores. If it only validates the last slice in a 6 slice incremental backup, what good is that? Here I thought it was going to validate each slice on completing each backup. I did test the restore and it did expand the single TIBX file to show each incremental with the full. So you can pick which date you wanted to restore from.That was kinda neat. I guess I discombobulated the meaning of "Validate the latest diverse backup only".  Thanks again, Cheers!