TI 2020 version cleanup
Has anybody else experienced the version cleanup in TI 2020 as a medium sized disaster?
As probably nearly everybody else I have limited storage capacity for backup at my disposal.
Up to TI 2019 I could define the complete backup (including all full + incremental chains) to not become bigger than let's say 6500 GB. If that condition was met the oldest chain was purged to free some space on the backup medium.
Well, this switch is missing when using the new *.tibx format. I tried »Keep backups no longer than 42 days« instead and additionally defined 5 weekly backups before a new chain should begun.
To avoid possible confusions: I'm talking of »data tombs« with slowly changing content here; thus weekly backups are absolutely sufficent. The boot volume is backed up way more frequently.
Well TI 2020 somehow begins a new chain after 5 weeks. But due to a commented bug (?) / feature (?) the first version of the backup is always kept as the »new chain« (the new *.tibx in TI 2020) is not really new, but apparently a differential addition to the original backup version. Unfortunately this second (differential) backup is of approximately the same size as the original; in my case another 6.5TB. As I've tested removing the first *.tibx immediately renders the remainder of the backup useless.
Thus even when the version cleanup were working (doesn't look like as I find versions older than 60 days on my backup medium) the minimum backup space required in my case sums up to something like 13TB as soon as the second »chain« begins in week 6. That's about twice the space defined and needed in TI 2019.
Am I misunderstanding or doing something wrong here? Or did I actually get it wright that the »brand new (well, not completely in the meantime) , space saving« TI 2020 *.tibx format inevitably requires at least twice the space demanded by the old TI 2019 *.tib backups as weeks pass by and a second »chain« is begun?
If somebody's got a hint on how to avoid the excessive storage famine in TI 2020 described above I'd be glad to hear about it. Otherwise I'll probably have to revert to TI 2019.
Hi Steve,
thanks for your fast reply!
I've got a boot drive and three big disks (8TB or more). #1 contains multimedia, #2 installation and business files, #3 is a big song archive.
All drives are backed up completely (i.e. not 'files and folders', but complete disk). The HDDs aren't partitioned, just big, simple volume, non-bootable NTFS drives.
They are backed up to a Synology NAS via 10GBe SFP+ connection. Currently that's a RAID5 with ~50TB capacity.
Backup is done on a weekly basis. As the data on the big drives don't change very often, that has been absolutely sufficient in the past.
For the big data disks I've followed the standard and defined a full backup followed by 5 incremental backups, then a new version should be started.
A small *.tibx file has been present on my system only one single time — after I did a manual version cleanup, which left a 12kB file and two giant archives, which allegedly contained only the very last version of the backup.
The normal procedure as I observed it: Starting and completing a backup creates a huge file (e.g. DriveE.tibx, ~6.5TB) . It grows a bit over the next five weeks (to ~7TB). Then another huge file DriveE-0001.tibx is created; again ~6.5TB. However as told it's not a completely new version as I configured and intended, but depends on the first archive (DriveE.tibx). When I delete the original DriveE.tibx, DriveE-0001.tibx instantly can't be accessed any more.
As you suggested I've switched my config to 'Keep only a finite number of chains'. I can't tell whether this is working for me; it will take about a quarter of a year till I see whether old giant archives are actually purged or whether just new file monsters are added to my backup. I'll post the results here when I've got them.
---
As mentioned in my original post above I never run into such problems with ATI 2019 and the old *.tib format. Manually deleting an old chain there didn't cause any harm to the newer chains. And the 'Don't grow bigger than xxx GB' rule worked perfectly. And I could move and rename backups. And could mount a backup as a virtual drive (I don't like the Explorer very much as file manager). Well, the latter points are documented restrictions of *.tibx I simply have to accept or turn back to ATI 2019. The 'double whammy' concept however (at least two giant files as soon as the second 'chain' begins and from there on ever after) is causing me kind of a grim stomach.
Therese
With *.tibx backup you should not manually delete files using Explorer; the initial files remains even after the first backup is deleted (although it is very small). To manually delete backups do so from within ATI. One limitation of the *.tibx structure is that you have to delete an entire backup chain (this may not apply to the current chain, I cannot remember at the moment).
Ian
I had to delete some of the backups manually cause of running out of backup storage space.
As described above from within ATI 2020 even the minimum backup size after a manual version cleanup (keeping only the very last version) is approximately twice the size of the data to be backed up — at least if you're dealing with data that are very hard to (further) compress: videos, mp3s, archives...
And as described the direct deletion of of a giant backup file failes grandiosly.
Manually deleting all backup files to start a new backup also failes as the program runs into a 'file not found' loop making it necessary to delete and recreate the whole backup job.
I registered myself for the ATI 2021 Beta program, but so far I can't see any differences to the 2020 version regarding handling of backup chains. I'll give it a try for two more months to see whether the automatic version cleanup works.
Therese, we seem to be at cross purposes. You can manually delete backups from within ATI without resorting to cleanup rules.
As you can see there are many backup chains listed (there are some older ones that are not shown). So if I select the las chain it will save 139 gig.
Ian
Hmm — the window shown in the screenshot above is reachable via 'context menus' (left click on down arrow right to backup name) --> 'version cleanup'.
As I've told above I've done so for one of the big 6.5TB backups. I deleted everything despite the very last backup.
What was left on the backup volume was one 12kB file as expected — plus two additional files of 6.5TB each. That's approximately twice the size of the data backed up. And that — sorry for the wording — sucks.
Imagine this times three (for three HDDs), another TB for the (more frequent) backups of the boot volume, and add just one other huge backup file — and your 50TB backup volume starts to run out of space. A problem I never run into with ATI 2019. When only the last chain was left there its size was in the order of magnitude of the data backed up, not twice that size.
Thus — to possibly clarify my initial concern: When you want a kind of minimal backup set of slowly changing data (basically one chain would be sufficient), per my observations so far ATI 2020 seems to occupy about twice the storage space claimed by ATI 2019. This problem seems to arise from the factor that 'new' chains in ATI 2020 don't seem to be actually completely new but rather look like differential additions (unfortunately of about the same size as the original) to the first backup which thus has to be kept, too.
Correct me if I'm wrong with the above statement. But whatever the technology within the *.tibx format actually is, it produces the 'result' mentioned in the third paragraph of this post.
Therese, thank you for the extra information about your computer setup.
I've got a boot drive and three big disks (8TB or more). #1 contains multimedia, #2 installation and business files, #3 is a big song archive.
All drives are backed up completely (i.e. not 'files and folders', but complete disk). The HDDs aren't partitioned, just big, simple volume, non-bootable NTFS drives.
They are backed up to a Synology NAS via 10GBe SFP+ connection. Currently that's a RAID5 with ~50TB capacity.
Backup is done on a weekly basis. As the data on the big drives don't change very often, that has been absolutely sufficient in the past.
For the big data disks I've followed the standard and defined a full backup followed by 5 incremental backups, then a new version should be started.
Just to clarify the above, you have 4 separate backup tasks here, 1 for each of your 4 disk drives, and each backup is of Disks & Partitions using the Incremental scheme (full + 5 incr). All going to your Synology NAS on a weekly schedule.
The normal procedure as I observed it: Starting and completing a backup creates a huge file (e.g. DriveE.tibx, ~6.5TB) . It grows a bit over the next five weeks (to ~7TB). Then another huge file DriveE-0001.tibx is created; again ~6.5TB. However as told it's not a completely new version as I configured and intended, but depends on the first archive (DriveE.tibx). When I delete the original DriveE.tibx, DriveE-0001.tibx instantly can't be accessed any more.
This is correct for the way that ATI 2020 & later work when using .tibx files.
There are no separate incremental files with .tibx - all the 5 incr along with the initial Full backup for the chain are stored in a single, consolidated file. So this single file will grow in size as new incremental backups are added.
The pattern you noted, i.e. when a new chain is started a new file using -0001, -0002 etc is created to store that new chains files again in a single consolidated file.
When automatic cleanup runs, then the first file of the original chain is reduced to just 12kb size and holds metadata for all subsequent files, so it is essential that this is not deleted, nor any other of the following .tibx files, outside of the tools provided by ATI.
Each subsequent -0001, -0002 file etc also contains linkages to the prior files.
If a situation does arise when you need to prune the number of backup .tibx files, then the safest method is to use the 'Clean up versions' tool from the ATI task context menu - this will allow you to remove any files safely while correcting any metadata and linkages held in other existing / remaining files.
Your switch to using 'Store no more than X recent version chains' will be easier to visualise and manage and should help you to store the required number of backup files on your Synology NAS. You should keep an eye on how this is progressing so that you can adjust the X value for the number to be stored if you see that the size of data will lead to any space issues on the NAS.
Acronis has published a lot of information about the new .tibx format files and limitations - some of which will need updating with changes being introduced back again in the ATI 2021 beta version, but is recommended reading!
KB 63518: Acronis True Image 2020: do not delete first tibx file
KB 63227: Acronis True Image: Do not delete .TIB or .TIBX files outside of Acronis True Image
KB 63498: Acronis True Image 2020: new tibx backup format FAQ
KB 63425: Acronis True Image 2020: Limitations of tibx backups
KB 63445: Acronis True Image 2020: how to view and manage backup versions in new backup format
KB 63444: Acronis True Image 2020: tibx backups in local destinations
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).
Man könnte einen neuen Backuptask erstellen und das alte .tib Format verwenden, dann sind die alten Laufwerksbackup-Optionen zurück (Edit: Nachdem das Backupscript geändert wurde, kann man die Laufwerksbackup-Optionen noch einmal ändern, bevor das erste Backup gestartet wird).
Möchte man die alten .tib Archive haben, muss man, wenn ein neues Laufwerksbackup erstellt wird den Backuptask mit "Backup später" speichern, dann das Backupscript bearbeiten und aus ".tibx" ".tib" machen.
https://forum.acronis.com/comment/510834#comment-510834
English version:
https://forum.acronis.com/forum/acronis-true-image-2020-forum/how-creat…
@Steve Smith: Thanks for the comprehensive information; you got me right (4 different backup tasks to the NAS, 3 of them on weekly schedule). And I think I got the procedure; in short: Don't delete or manage anything via your favorite file manager, instead do everything within ATI. I'm just not amused the same minimal backup set (only 1 chain) requires about twice the space than ATI 2019 did before.
@G. Uphoff: Of course I could edit the appropriate backup script to revert to *.tib instead of *.tibx — even though the way to do it feels like a gunshut from behind through the chest directly into your eye; i.e. veeeeerrry complicated. When considering this IMHO the main question is: Why 'upgrading' to ATI 2020 at all, when you don't like the new quasi-enforced *.tibx format cause of so many detriments?!
@Developer team: As apparently I'm not the only one not being completely convinced of the *.tibx format maybe it would be a prudent step to offer the user a switch 'Old / New Backup Format' for newly defined backup tasks. Just as a suggestion.
Therese Telepski wrote:@Developer team: As apparently I'm not the only one not being completely convinced of the *.tibx format maybe it would be a prudent step to offer the user a switch 'Old / New Backup Format' for newly defined backup tasks. Just as a suggestion.
Hello Therese,
I'm afraid the chances of returning the .tib format are rather low, but we continue gathering the feedback and converting it to the internal change requests. I've noted your feedback in the existing tickets
TI-177349 Return cleanup option Keep size of the backup no more than [defined size]
TI-190052 Independent Full backups