Skip to main content

Disk backup filename: structure/format

Thread needs solution

The default standard backup filename is: xxxxxxb1s1v1.tib
1/ What is the meaning of "b", "s", and "v"? (where 1 can be any digit/number) and,
2/ When "v1" can increase?
Regards, Eric

Attachment Size
acti.jpg 150.37 KB
0 Users found this helpful

Name design here. The v is usually always 1 if storage disk is NTFS. If storage disk is FAT32, the V could be infinite--which is not so good.

http://www.acronis.com/en-us/support/documentation/ATI2015/index.html#2…

I would encourage you to stop using your existing backup task. Instead, create a new backup task with automatic cleanup and restrict the number of incrementals to a smaller number. Read link GH25 for more details. The new task could be set up similar in design as GH12 if you wish to continue using the Full plus X incrementals type backups.

GH25. Understanding differences between Inc and Dif for Safety

GH11. Create Custom Full Backup Scheme.
Keep 4 versions (chains). Full backups only.
The 4 is an example only with user choice for whatever number of chains to be retained best fits the individual needs..

GH12. Create Custom Incremental Backup Scheme.
Keep Full plus 6 Inc per chain, Keep 4 chains.
The 6-4 is an example only with user choice for whatever number of chains to be retained best fits the individual needs.

GH13. Create Custom Differential Backup Scheme.
Keep Full plus 2 Dif per chain, Keep 2 chains.
The 2-2 is an example only with user choice for whatever number of chains to be retained best fits the individual needs.

Dear GraverH,
Thank you for your quick answer. I will follow your recommendation.
But: what do you mean by "Restricting" the number of increments? Do you suggest 1 or 2, or <5 or <10 or ? increments?

incremental=inc
I noticed that your number of inc is up to S19 which is not bad but if your number of inc just continues to mount, then the increasing number of inc is just asking for trouble. I'm sure you read my link GH25. This illustrates that each inc has data not stored in other inc so if you needed to restore S19, the program would be restoring all 19 pieces. If any of the earlier inc files should be corrupt or non readable which breakes the restore chain at that point of break, a restore would only be possible backwards from the break point.

My point being that more frequent FULL backups (fewer incremental) reduce the risk of a possible non-restorability. I don't know what the magic number of incremental's should be but knowing the risk helps to plan for dual backup coverage. At lot depends upon the amount of data changes or how static your data is. Any number is arbitrary but you may want to consider Full type backups at least monthly with two different storage tasks with Full date being created only about two weeks apart from the other task. Any number from me is arbitrary as you know your needs better than I. I just wanted to alert you that if you do not have some time of automatic cleanup to control the number of incremental's, that you need a new task to accomplish that rule.