Can I force incremental individual .tib files?
I use a backup scheme with incremental backups. Up to now, the backup location was on a network share, and Acronis True Image 2021 created a separate .tib file for every incremental backup.
Now I have a slightly different setup. The final location is still on a network share, but I let TI create the backup files on a local disk first, before I copy them (in a post-command) to the share.
This works fine -- except now TI doesn't create individual files for the incremental backups anymore. The result of this is that I have to copy the full backup to the share every time I create an incremental backup.
I found this article that explains this behavior, but it's for TI 2020: https://kb.acronis.com/content/63516
The way I understand this article, I have three options:
- Use differential backups. In this case, the base backup and each differential backup would be in a separate .tibx file.
- Use incremental backups and deal with the downside that I need to copy the full size of the backup file for every (incremental) backup.
- Switch to a different product that creates individual backup files for incremental backups.
What I hope for is that Acronis understood that this approach has downsides and provided a way to force individual, separate files for incremental backups since then. Did they?
This is making it difficult to maintain offsite copies of backups. (The share to which I copy the backups is backed by offsite storage, but it now also has to transfer the full backup file for every incremental backup. This is not good.)
Thanks, Ian.
it (as far as I can determine) only updates the most recent *.tibx file and the initial *.tibx (which after the first cleanup is only 12kb in size), so you only need to copy those two files.
That sounds right, but in my case the most recent .tibx files are over 100 GB and all backups go to offsite storage. That's too much to send out every day from multiple systems. Incremental backup files are only a few GB to send out, and that's quite viable.
Thanks for the link to the hack. I'm not sure whether I'll do that... after all, this is for a backup that is supposed to be guaranteed to work when I need it for a restore. But it's interesting to know that Acronis is aware of this shortcoming for a couple years now and decided to leave this product half-broken for 3rd party offsite storage solutions.
If you are doing this daily for multiple systems, then I can see the problem with the multiple 100 GB+ files. There other backup solutions that support multiple third party cloud storage providers, but cannot remember which one off the top of my head (these things have a tendency to change, with the ability to do so being added, changed or removed).
One way of getting backup redundancy would be to do backup to Acronis cloud using two or more different servers - but not sure if you can purchase sufficient cloud storage to ATI/ACPHO, although you could do so with Acronis Cyber Protect 15, which depending of the version selected offers the ability to manage software and driver updates for client PCs. However, this solution would be rather expensive.
Update: If the backups are stored on a NAS, the NAS may have the ability to upload the backup to cloud storage - as many NAS devices support deduplication and other advanced features this reduces the amount of data sent to the cloud. The CloudSync package on my ancient (7 years +) Synology NAS allows simultaneous syncing to multiple cloud storage including Box, DropBox, GoogleDrive and more.
Ian
Gerhard, depending on what your source data here is, then you may be able to keep using .tib files with separate incremental files if you are able to switch to using Files & Folders for the backup type.
By default, all backups using Disks & Partitions now use .tibx files, which in turn now consolidate incremental slices within the same backup file as the initial Full backup for the current version chain.
Note: you cannot use Files & Folders if you are including the Windows OS partition in the backup as this method cannot capture files, folders etc locked by the OS during operation, but it can be used for data such as documents, images, videos, music etc.
You could also consider setting up a separate backup task that writes directly to your network storage location, which would then only write the incremental slice data across the network. A further option would be to use FTP for the connection, which forces Acronis to use .tib files with separate incremental files. Note: FTP is insecure as Acronis still don't support using SFTP! So best to use password encryption for the backup task(s).
Thanks, guys, for the suggestions.
I really want a disk/partition backup, for ease and speed of restoring. I also just moved from creating the backup on a network location to creating it on a local partition and then syncing it to the network location because on some systems, the full backup to the network location would take too long and affect work on the systems.
And no matter how I slice it, with .tibx files I get too much traffic through my Internet connection.
Unless, of course, I use the Acronis Cloud; presumably they have a mechanism to only upload what's changed. But that's too expensive.
So I guess I'll see how differential backups work out. Should be ok; it's a bit more storage, but it may not be that much more that it matters.
I even tried to create a share for the local backup directory and create the backup on the local share, hoping that this would force .tib files. But somehow Acronis is smart enough to detect that it's a local share and used .tibx anyway -- but it's not smart enough to realize that for some scenarios, .tibx files are just bad.
The weird thing is that I have a system with an incremental disk backup to a local directory -- and it does create .tib files.
One thing that's specific on this one is that the path where the .tib files are created goes through a junction point. I tried to recreate that scenario on my new system, but it seems TI 2021 doesn't allow junction points as backup target location anymore.
This backup configuration was created with an older version of TI. I don't remember how long ago that was. The TI running there is the current 2021 (build 39287).
It at least confirms that there are circumstances where TI, without any hacks, does use .tib for disk backups to local backup locations.
I just wanted to leave my "solution" here: the work-around created by Steve and linked above by Ian. Thanks to both of you!
Excellent!
Ian