Backup Numbering Strangeness

This is a sign that ATI has lost track of some file in your backup chain.

I wouldn't try to tweak the backup back to normal. The best thing to do is to delete your backup task with the corresponding TIB files and recreate the task.

Thank you. But I'd like to understand why, even when starting a new backup chain, the file name seems to be starting off differently. I was hoping to not have to recreate the task, but I will if need be.

Ron,
Unfortunately, this numbering is under the control of 2011 and C2G users have no control over it.
http://kb.acronis.com/content/19313

For what its worth. I have C2G putting backups to 2 external eSata's plus one SATA internal.

The externals have the correct numbering but the internal has the new 2011 way.
The externals are only attached during the backup period so they are not exposed to 2011 eternal hunting for old backups.

I don't know whether a new task will solve the issue or not. It did not on the internal disk.

Thank you for that information.

The article you refer to is for TIH 2011, but I suspect a similar scheme is present for 2010.

What I am concerned about is not the naming of the incremental backups, which seem to be correct per the scheme, but rather the naming of the initial full backup when the chain starts. The name I have defined in the task is "RonBP-". Yet the name of the first backup -- the full backup -- is coming out "RonBP-3". Then, the second backup in the chain, which is the first incremental, is "properly" (according to the scheme) named "RonBP-32". I am trying to understand how that spurious "3" crept into the name.

And I have checked the backup task in Edit mode; and the original Backup should still be named "RonBP-".

Other than the cosmetic differences in the appearance, the integrity of the backup should be ok but you can validate via the CD anytime at your convenience.

The fact that it chose 3 would seem to indicate that TI became aware of the others and made the number change on the next full backup--but who knows. Have you looked inside set1 or set2 folders to see how they were numbered--not that it really matters or changes things.

You can leave as is or create a new task. If using version 2010, you many have a better chance of proper number with a new task. If you do decide to create a new task, then use a new folder to hold your new set0 folder and don't forget to update your parameters file with the new folder name. I would also change the name of the backup--just for clarity--if you do a new task.

If it were me, I would just continue using the old task. If you have your task set to validate at time of backup, I would check the log file just to make sure you have no errors. It might also be prudent to boot from the CD and validate the backup.

Listed below are the CD validation procedures for the 2010 and 2011 versions.

Click on image to enlarge.

Thanks, Grover.

I don't have enough "sets" to go back to when it was naming normally. I think I'll just leave it as is. I always validate, and the validate has always completed without errors. Good idea about trying to validate from the Rescue CD, though. I've never tried that.

-- Ron

Ron,
The number scheme issue happened to me a while back.
To "fix" the issue I did the following.
I ran C2G's script !_FORCE_NEW_CHAIN.bat followed by Acronis_PreProcessing_task.bat
the above had the effect of rotating the existing chain into history.
I then went into acronis clicked "operations" "more" "clone backup settings"
This gave me two backup tasks the orginal and a new virginal incarnation of it.
On the original I did "operations" "more" "delete" (let it complain about not finding files)
then proceeded to do "operations" "more" "remove from list" (accepting the warning about what that action means).

I then confirmed the clone of the job had the desired filename (which it did) and then proceed to run the job.
The job did produce the desired/expected filenames and has done so ever since.
I never bothered to figure out why acronis insisted on creating new full backups with erroneous digit as part of the base filename.
I agree with grover Other than the cosmetic differences in the actual filename the integrity of the backup chain is fine.

Thanks for that information. I will give it a try.

And yes, I agree, especially since the validation works OK, that it is just a cosmetic thing.

-- Ron

oracledba wrote:

Ron,
The number scheme issue happened to me a while back.
To "fix" the issue I did the following.
I ran C2G's script !_FORCE_NEW_CHAIN.bat followed by Acronis_PreProcessing_task.bat
the above had the effect of rotating the existing chain into history.

Ok, I did that with no problem.

I then went into acronis clicked "operations" "more" "clone backup settings"
This gave me two backup tasks the orginal and a new virginal incarnation of it.
On the original I did "operations" "more" "delete" (let it complain about not finding files)

I do not see an item labeled "Operations". I do see both "clone" and "delete" on the right-click menu when I click on the task under "scheduled tasks". So I did both of those without a problem.

then proceeded to do "operations" "more" "remove from list" (accepting the warning about what that action means).

Since I don't see an "operations" item, I couldn't do this. What are you "removing from list"?

I then confirmed the clone of the job had the desired filename (which it did) and then proceed to run the job.

Well, I did everything except the "remove from list" and it is still using the -3 numeric suffix. Possible whatever it is you "removed from the list" is a critical feature. Can you be more specific? I'm using TIH 2010. Is it perhaps the backups listed under Recovery/Disk Backups?

Thanks.
-- Ron

Ron,
sorry you are having issues.
The instructions I provided were for TI-2011.
If you are TI-2010 that would explain the issues you are seeing.
I no longer have TI-2010 installed hence can not offer insight with version specific questions on it.
The remove from list menu item that I mentioned has the effect of deleting all meta-data records of that job from the true image catalog tables.
I suspect that this removal action is key to the solution.
The reason why I suspect this key is because the entire problem is caused by the TI dbs/catalog being wrong/confused.
Because the catalog is wrong it is causing our ".tib" files to be miss-named.
By removing the job from the catalog we wash away the fubar entries and the bad things they had caused now go away.
The clone process that we performed prior to the removal was for convienence only.
I simply wanted to minimize the amount of data entry one needs to perform to recreate the jobs.
I do not recall where its found but I seem to remember that TI-2010 did have delete/remove/purge function for its jobs.

Hope this helps.

Attached are 3 screen captures showing the 2010 options.

The first two show how you can edit existing tasks in 2010. One of these options available is the clone or delete, etc.

The 3rd attachments shows how you can delete the actual backup files should you feel the need to.

The reference to "Remove task from list" is a 2011 option.

Thanks, Oracle.

If I understand you correctly, I think what I need to do in 2010 is to navigate to the recovery tab where there is a list of Disk Backups, and then delete those backups. I'll try that this evening and see how it goes.

-- Ron

Thanks, Grover.

My interpretation of your recommended process as transposed to TIH 2010 did not work. There must be something else, other than deleting the disk backups from the list (the actual files do not get deleted as they have been rotated out of the set0 folder) that needs to be done with 2010.

Of course, I could just set up a completely new task, as Grover suggested, but since this issue happens from time to time (and is merely cosmetic), I would rather see if I can find a fix, than just start over.

-- Ron

Ron,
In post #9, would you mind editing the first quote and remove the email address listed there. This address was accidentally put there by the program and should not appear.

It's very unlikely that Acronis will make any more fixes for the 2010 version.

OK, Grover, I removed the email address. I don't expect any fixes for 2010 (and from reading some of the issues being posted, I'd wonder about fixes for 2011 also!). I'm just trying to see if I can find a workaround for my problem short of generating a brand new backup job.

Do you think that deleting archives.xml might get the backup numbering scheme to "reset"?

Yes that was to be my last resort suggestion.

If you do that, also use the "Force new chain" option so as to put the "trigger.txt" file into each of the set0 folders you are using.

If you are also using any task which do not involved C2G, you might want to consider moving those files as well as TrueImage will be starting with a clean slate for backup file numbering.

Good luck.
Grover

Grover,

Deleting archive.xml is not going to work (almost positive of that). Oh, I deleted it, and a new (and empty) one was created when I started TIH. But when the existing job was cloned, a new script was generated in C:\ProgramData\Acronis\TrueImageHome\Scripts. This is the same script that the original used, and (examining that script with Notepad), we can clearly see where it has set the name to RonBP-3.tib and NOT RonBP-.tib.

However, after running "Force New Chain" and then running Acronis_PreProcessing_Task to move the files out of set0; I went into the existing task and edited the archive location (which, when I opened the task, was not even pointing to the correct piece of hardware) to reflect the proper name and location. This seems to have forced a change in the above Script which now reflects that the name is RonBP-.tib

We'll see what happens later and whether this simple edit works without messing something else up.

Good thinking. The edit should make it start with the correct name. The renaming would not work if there were files in the folder--it is my guess.

when you use the force new chain, you do not have to run the pre-processing task. C2G will move the files itself on the next run of the software when it sees the Trigger.txt file and this is before Acronis begins the backup.

I ran the pre-processing task to ensure there were no files in the destination folder when I renamed or edited the backup task. I don't know if it would have made any difference, but I wanted to clean out set0 without deleting the file for this project.

Again, good thinking. That's getting potential complications out of the way.!

OK, finally got back to normal numbering. I'm not sure which of the steps in the sequence below are absolutely essential, but here they are:

1. Delete archives.xml
On my W7x64 machine, there is only one copy located in: C:\ProgramData\Acronis\TrueImageHome\Database

2. Run !_FORCE_NEW_CHAIN.bat
3. Run Acronis_PreProcessing_task.bat
4. Start Acronis TIH 2010
5. On the Recovery tab, right click on the misnamed Recovery items and delete them. (Since these are in set0, and you have already moved them out of set0 in steps one and two, the files should be safe, and you can always navigate to them if needed).
6. Edit the original task, changing only the location of the Backup Archive to what it should be.

The following is for advanced Windows users only, as it involves going into normally protected areas of your computer:

What seems to have happened, and you should probably check before and after to make sure your problem is the same as mine, is that the Acronis generated backup script, a *.tis file found on my computer at C:\ProgramData\Acronis\TrueImageHome\Scripts has an entry called "uri=" in which the wrong backup file name is listed. Editing the task seems to have the result of changing this name back to what it should be. (This *.tis file can be read using NotePad).

I have not investigated the process that causes this to get mis-set in the first place.

 thanx a lot