Skip to main content

Can someone explain the numbering scheme?

Thread needs solution

Since I switched to SSD's I went from manual backups to scheduled. 

My settings are:
Create a full version after every 3 incremental versions.  Store no more than 3 recent version chains.  My schedule is every Monday/Thursday at 11:30 PM.

After a month, I had a look at my backup folder. I see the dates and names indicated below. I'm not sure exactly what's going on. The first two sets (4) and (1) seem to have gone OK, but the latest look wonky to me.

Filename date size
ZERO(4).tib 2012-02-21 12:51 AM 46,568,043
ZERO(4)2.tib 2012-02-23 11:32 PM 716,170
ZERO(4)3.tib 2012-02-27 11:33 PM 1,446,487
ZERO(4)4.tib 2012-03-01 11:35 PM 2,488,014
ZERO(1).tib 2012-03-06 12:53 AM 47,392,918
ZERO(1)2.tib 2012-03-08 11:32 PM 658,508
ZERO(1)3.tib 2012-03-13 04:15 AM 2,954,548
ZERO(1)4.tib 2012-03-16 04:07 AM 4,078,570
ZERO(2).tib 2012-03-20 12:54 AM 47,392,918
ZERO.tib 2012-03-22 11:34 PM 2,023,354
ZERO3.tib 2012-03-26 11:33 PM 1,027,057
0 Users found this helpful

For the internal ati database to keep track of backup files it needs to uniquely name them in a meaningful way. Adding those numbers to filenames is part of how it tries to do this. Unfortunately, this naming protocol is not plainly addressed in the userguide even though veteran users have complained before that the numbering scheme is at best enigmatic. According to Acronis, here is how it's supposed to work:

http://kb.acronis.com/content/19313

Basically, the first suffix denotes a file in a sequence of backups in a backup set. Until one set is complete, then the first number is in parens and denotes the number of the backup set and the second number denotes the order in the sequence within a backup set. So, if you have incs or diffs, the ones in the same set should have the same first suffix (unless there is only one set so far in which case they will have different numbers). The second suffix is the number of the file within in the set unless you have only one set in case there is only a first number and that represents the number within the sequence. This is very intuitive, isn't it? However, jsut to complicate things, ati doesn't always follow this protocol -- as you have seen -- which is maybe why ati sometimes orphans backup files. Also, at some point, ati will delete or overwrite old files and number might be used again.

You can search through the forums and find other threads on this subject,

http://forum.acronis.com/forum/27942 h

ttp://forum.acronis.com/forum/29741

but they don't shed enough light to answer your question.

So, if you figure it out, let us know, and let Acronis know too. ;)

Scott has provided a good summation of the issue. His link best describes what you should expect.
http://kb.acronis.com/content/19313

After you switched to SD's, did you start a new task? or did you ever edit the task?

If the tasks are being validated, the backups should be good. My personal preference would be to start a new task and point the destination to a new empty folder.
This is another example of what you might expect except this example has more Dif than your 3 and the first two chains have already been deleted as the task has progressed.

http://forum.acronis.com/sites/default/files/mvp/user285/folders/2011-d…

Moving to the SSD was a clean install--no thanks to Plus Pack, though I think I understand what went wrong now

Before setting up the new task I moved my last full backup to a folder named '2011-11-16 keep' and marked it read-only.  That would have been the only thing in the folder.

At some point since, I edited the task to configure email, but didn't change any other settings.  All the email messages have indicated success.

I guess it just bothers me that the last three aren't named Zero(2).tib, Zero(2)2.tib, and Zero(2)3.tib.

IN effect, ati started over so the first set gets marked only with the numerical suffix without parens, the next set should have the set number in parens followed by the sequence number (not in parens). Since you already have some sets using set numbers in parens, it might skip ahead when deciding what set number to apply.

Just wanted to follow up with the latest two files, both because it adds more confusion and because I noticed a different issue.

Filename date size
ZERO4.tib 2012-03-30 05:37AM 1,051,992
ZERO(3).tib 2012-04-03 01:01AM 52,586,175

So what happened to ZERO2.tib? Why did ATH fail to wake my computer in 3 out of the 13 scheduled events? I've configured my start menu for 'Sleep' so I'm pretty sure I didn't power-off by mistake.