Reducing Backup file size - V12 format
Hey there,
we are using a GFS scheme for our backups and we use the V12 format.
A full backup is done on each first of the month, then a differential each saturday and incrementals on each day.
The retention retention rules keep the daily incrementals for 2 weeks and the weekly differentials for 8 weeks.
So each month a new file is generated and after 8 weeks, these files contain only the full backups.
But the size is as large as the maximum size that was ever needed during the "active" period of the file.
Since 2017 a shrink feature was announced, but was often postponed.
So i have 2 questions:
- will the shrink feature come, and if yes when?
- Is there any chance of reducing the size of these old backups?
One point that is very disappointing for us as company:
We pay since years for maintenance, but the release cycles are extremely long.
V12 was rolled out in 2017 I think and the last service pack was rollled out in August 2019, the one before in october 2018....so the release cycles (even of servicepacks) are quite long.
Regards
Sven
Hello Peter,
well the question is legitimate.
The answer is quite simple: it is recommended by Acronis to use it and so I used it.
Now create all backups again to use v11 is a big effort.
The issue is not to use permanently the least place as possible but to reduce the size of tibx files to a size that it really needs.
The shrink feature (internal ID: ABR-86450) was announced mid of 2017 for the update 2...(see link: https://forum.acronis.com/de/forum/acronis-cyber-backup-125/difference-… post #1)...
Now we are 2,5 years later..and this feature is still missing.....very disappointing that features are postponed in such a manner....
S:
Hello Sven,
thank you for a new post on Acronis forums!
This is how the Version 12 format works:
After the first full backup, all other backups are saved to this archive in incremental mode. Physically all data is located inside one file as opposed to the version 11 format where each backup is stored in a separate .tib file.
When a certain backup expires due to the pre-defined retention rules, the backup algorithm just marks these outdated backup blocks as “free” ones. The initial archive still occupies the same space on the storage as before, however all newer backups will be written to the “free” blocks first, and only if all the “free” blocks are filled, the total size of the archive will be increased.
- will the shrink feature come, and if yes when?
Unfortunately, I can not provide you with an exact time frame. Shrink feature in version 12 format is still in the roadmap (RM-358).
- Is there any chance of reducing the size of these old backups?
I suggest that you open a case with Acronis Support Team and ask the engineers to help you reduce archive size (the size of deleted data should be >= 10% of the archives’ physical size).
One point that is very disappointing for us as company:
We pay since years for maintenance, but the release cycles are extremely long.
V12 was rolled out in 2017 I think and the last service pack was rollled out in August 2019, the one before in october 2018....so the release cycles (even of servicepacks) are quite long.
We understand your disappointment regarding long release cycles. However, I advise that you use your maintenance contract in full: open support cases when remote assistance is required (as I suggested above for decreasing archive size), when you think that found a bug and testing from our side is required).
Hello Maria,
Unfortunately, I can not provide you with an exact time frame. Shrink feature in version 12 format is still in the roadmap (RM-358).
Hmm really? This feature is planned since 2017 and still no guess when it is available?
It´s extremely disappointing that a löt of features are only promised but never came.
As example the WOL feature that was dropped with V12.5 never came back within the last years although it was promised...
I suggest that you open a case with Acronis Support Team and ask the engineers to help you reduce archive size (the size of deleted data should be >= 10% of the archives’ physical size).
Maria, I think you remember the support cases that I opened and that the success was very small.
I created reports, sent infos and the most common solution was "recreate the plans" or "reinstall the product".
So if there is no option for me to do it on my own or any workaround to shrink the size there is simply no solution .
Would replication help me?
If I replicate a backup to a second location, will this reduce the file size to the size that is really necessary?
We understand your disappointment regarding long release cycles. However, I advise that you use your maintenance contract in full: open support cases when remote assistance is required (as I suggested above for decreasing archive size), when you think that found a bug and testing from our side is required).
As mentioned above, most support cases ended in the solutions taht were not very helpful.
When is the next service pack scheduled and when will teh next main release come?
Are there any plans ?
Sven
Hello Sven.
Please check your Private Messages: I have sent you instructions on how to proceed if you do not want to open any support case.
Hi,
Could you share the information to reduce the archive size please ? The issue is that the TIBX archive size still grows a bit after each backup even if reusing free blocks in it. For example, if a customer has a quota of 200GB with a 200GB archive, he can't backup anymore even though there's free space available inside the archive because a new backup would lead to a TIBX archive size of ~202GB...
Thank you in advance,
Olivier
Hey Olivier,
Where do you know from that there is enough space in the file and(or that it grows?
Disrespecting this:
The proposed solutions I got from Maria were not applicable as I need to reduce the size of backup files that are "closed". I create each month a full backup and by this I have a tibx file for each month.
And so the tibx file has a lot of freed space because of retention rules.
The only solution to reduce this size is a replication job.
Regards
Sven
Hi Sven,
Thank you for the information.
I know there's enough free space inside the TIBX archive because I deleted all the backups expect the first full one.
Then when creating a new backup after creating 50GB of dummy data on the device to backup, the archive grows just a bit, few MB. Not a lot but it becomes a problem if the quota is reached.
To illustrate the issue, let's says I have a 200GB hard/soft quota available, meaning that I can't store more than 200GB. Following numbers are just here as an example.
Backup 1 Full 100GB -> OK - Archive TIBX = 100GB
Backup 2 Incremental 50GB -> OK - Archive TIBX = 150GB
Backup 3 Incremental 50GB -> OK - Archive TIBX = 200GB
Backup 4 Incremental 50GB -> NOK because quota reached = NORMAL
Deleting Backups 2 and 3 -> should be now ~100GB of available space inside the archive - Archive TIBX = 200GB
Backup 5 Incremental 50GB -> NOK because quota is reached = NOT NORMAL - Archive TIBX = 200GB
Now, if I increase the quota to 205GB for instance or if I set a soft quota limit to 205GB :
Backup 6 Incrementak 50GB -> OK - - Archive TIBX = 202GB
The fact that the archice still grows a bit after each backup is a real problem for customers... The have no other choice but delete the whole backup chain and start over again.
Olivier
olivier c wrote:The fact that the archice still grows a bit after each backup is a real problem for customers... The have no other choice but delete the whole backup chain and start over again.
Dear Olivier,
I've registered your feedback as a vote for the feature request RM-358 Shrink in Archive3. An estimated date for implication of this feature is yet unavailable.
Hi Ekaterina,
Thank you. Is the feature RM-358 linked to the Internal Acronis feature request ABR-86450 that was initially scheduled for 2017 ?
Best regards,
Olivier
Hello Olivier,
thank you for posting in this forum thread!
The fact that the archice still grows a bit after each backup is a real problem for customers... The have no other choice but delete the whole backup chain and start over again.
The instructions that I've shared with Sven were on how to select and delete a backup chain in the locally stored archive in order to reduce its size. Do you still need them?
Is the feature RM-358 linked to the Internal Acronis feature request ABR-86450
Yes, this is the same request.
Hi Maria,
Yes please, share the instructions to select and delete a backup chain in the locally stored archive
Thank you in advance,
Olivier
Hello Olivier.
Decrease local archive size
Size of deleted data should be >= 10% of the archives’ physical size.
Method 1
For the last chain in the archive only: if slices D7, I8 or I9 contain any unique (not present under other slices) data, deletion of D7, I8 or I9 will free some space.
Method 2
Delete all chains starting from full backup and including all differentials after it, but leaving next full backup: if slices F1- I9 (all of them) are deleted, all the space previously occupied by them will be freed*.
Note: removal of slices F1 - I3 only will not free space (until dependent slices D4 – I9 are also deleted).
Method 3
Delete the whole chain that does not have dependencies (the latest one, or the one starting from differential backup).
Example #1: if slices D4–I6 or D7–I9 (exactly all 3 of them) all disk space occupied by them will be freed.
Method 4
Delete the whole chain that does not have dependencies (the latest one, or the one starting from differential backup).
Example #2: if slices F7–I9 or F10–I12 (exactly all 3 of them) all disk space occupied by them will be freed since they do not have dependent differential chains.
We have the same problem !
Please Fix it...asap
Rocco Balzamà wrote:We have the same problem !
Please Fix it...asap
Hello Rocco,
I've registered your feedback as a vote for the feature request RM-358 Shrink in Archive3. An estimated date for implication of this feature is yet unavailable. In the meantime, you may want using the instructions from a previous comment on how to shrink the archive size.
Hello everyone,
I have a similar issue.
Have a 80GB full drive backup from 2019 and did a first incremental backup of +200GB.
So the tibx file is now 280GB.
I didn't want to blow up the backup size that much, so I've deleted the incremental backup (200GB), but the tibx is still 280GB.
Does that mean, that I now have 200GB blocked on the backup drive, which are now blocked and totally useless unless I use/run THIS specific backup job again?
This machine has 7 jobs and the space is usually more utilized by the other jobs.)
How to (manually?) shrink the TIBX to regain the 200GB?
I don't want to delete/loose the initial 80GB full backup from 2019.
Hello Robert.
In this situation, you can temporarily export the initial full backup to another backup location and then delete the whole .tibx backup archive on the original location.