Backup files with long number appended to *.tib file extension
I just didn't locate a discussion of this. I'm sure it's here.
What are the backups with a long number appended to the *.tib file extension. Do these occur after a restore? They are interspersed among my incremental backups. Some appear to represent repeat full backups. They are taking up a lot of space.
Thank you in advance
Kevin
If there is a FAQ on this just referred me to it
So the sequence is that a backup is given the usual name if it completes but if it is interrupted and then completes it is given the long name?
I hope that resurrecting this thread is acceptable as I am experiencing the same issue. Technical specifications of my computer are as follows:
Mother Board (EVGA E758-A1 3-Way SLI)
Mother Board Drivers (9.1.0.1012)
BIOS (SZ2E)
CPU (Intel Core i7 920 @ stock speed of 2.66GHz)
CPU Cooler (CoolIT SYSTEMS ECO-R120)
RAM (12GB Corsair Dominator (6 x 2GB) 240-Pin DDR3 1600 underclocked to 1333 with 7-7-7-21 timing.)
PSU (CORSAIR CMPSU-750TX 750W)
GPU (EVGA GTX295)
Video Drivers (196.21 WHQL)
Case (LIAN LI Lancool PC-K10B)
Hard Drives (4 Western Digital 1TB SATA drives, 1 CORSAIR CMFSSD-128GBG2D)
Operating System (Vista Ultimate 64 w/SP2)
3DMark06 ( http://service.futuremark.com/resultComparison.action?compareResultId=1… )
I have all of my drives in AHCI mode. I have Acronis True Image 2011 installed on my 1TB Western Digital C: drive in the default location. My target drive is a different 1TB Western Digital drive. When I run my backup (I exclude my data directories) I end up with exactly the same issue that Kevin Brady has. This is the output I get:
========================================
C:\Users\Kevin>m:
M:\>cd "Acronis New System"
M:\Acronis New System>dir/b
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF01.tib_0E798862-9774-41FD-B8EB-F610A325EA1A1.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0110.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0111.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0112.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0113.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0114.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0115.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0116.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0117.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0118.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0119.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF012.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0120.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0121.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0122.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0123.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0124.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0125.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0126.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0127.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0128.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0129.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF013.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0130.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0131.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0132.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0133.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0134.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0135.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0136.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0137.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0138.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0139.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF014.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0140.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0141.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF0142.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF015.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF016.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF017.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF018.tib
MyBackup.tib_1AD62701-6B82-4876-819D-206E4AA36ED71.tib_B1DF2DBD-0F9F-4231-ADA4-47853ED0CCF019.tib
M:\Acronis New System>
========================================
What would cause my backup to be interrupted? I did not experience this issue with Acronis True Image 10 Home on the same hardware with effectively the same software installed.
The auto-consolidation of your backups is failing. ATI creates this long-named files when you limit the backup chains by size (in the case where you ask to create a new full backup every N partial) or when you use auto-consolidation (in the case where you ask ATI to only create partial backups after the first full).
The auto-consolidation can fail for multiple reasons like a regular backup. The most common reason is lack of space since the backups that are consolidating are first copied, then consolidated. If the consolidation works, then the original backups are deleted and replaced by the consolidated ones. In short, you need a lot of space and some long time to process.
Delete your task from ATI (not remove). This will delete all tracked TIB files and the task. Delete manually orphaned TIB files from the backup directory.
Set up a new task.
ATI is most reliable when creating a backup chain with a new full every N partial, and limiting the backup size by setting auto-cleaning options to retain only the X most recent backup chains.
Pat,
Thank you for your quick reply. I really appreciate the depth and detail of your answer. I decided to see if the .tib.tis file was different than what my settings are reported as. Attached is my current config file that is located here:
C:\ProgramData\Acronis\TrueImageHome\Scripts
I do not see where I am using auto-consolidation.
Configure disk backup process:
Exclusions: *.tib"; *.tmp"; *.~"; 'C:\DriveKey\*"; C:\Graphics\*"; C:\NVIDIA\*"; C:\Users\Kevin\.VirtualBox\*"; C:\Users\Kevin\AppData\Local\Temp\*"; C:\Users\Kevin\Documents\*"; C:\Users\Kevin\Downloads\*"; C:\Users\Kevin\Music\*"; C:\Users\Kevin\Pictures\*"; C:\Users\Kevin\Saved Games\*"; C:\Users\Kevin\Videos\*"; C:\Windows\Temp\*"
Schedule: Turn on
Backup Scheme: Single Version
Disk backup options:
Backup Scheme: Single version scheme
Advanced:
Image Creation Mode: blank
Pre/Post commands: blank
Backup splitting: 700MB (CD)
Validation: Validate backup when it is created
Backup a reserve copy: blank
Removable media settings: Ask for first media while creating backups on removable media [?]
Screenshot settings: blank
Error handling: blank
Computer shutdown: blank
Performance:
Compression level: Max
Operation priority: Low
Network connection speed limit: blank
Notifications:
Snow notification message on insufficient disk space
Notify me when free disk space is less than: 100MB
Send e-mail notifications about the operation state: blank
I currently have 429.44GB of space free on my destination drive. I have never used partial backups before, only full backups. Please advise on how I can fix my single version scheme.
My guess will be to delete the task from ATI (not remove) as you suggested above and recreate the job from scratch (I have detailed notes on my configuration).
Again, thank you so much for your fast and detailed response.
Kevin,
It doesn't seem like you are using autoconsolidation or auto-cleaning. I have to guess that the splitting option that you have might be the origin of these long file names.
At any rate, your script is showing some archive name that is weird and you'd better delete this backup and start another one.
Why are you splitting the backup? Maybe you can try without splitting and see if that solves the issue.
Pat,
As I anticipated. I'll nuke the backup.
I split the backup up so that I don't have high fragmentation on my drives. I was also in a situation once where I had to use multiple CDs to restore a backup.
If splitting the backup into smaller pieces causes this issue then I wonder if Acronis will:
1) Continue to support splitting.
2) Resolve the naming issue.
3) Mark the issue as by design.
Thanks for your insight.
Kevin,
If you are not using your backup disk for data intensive application, you should not worry about fragmentation. ATI is not very good when you need several CD/DVD to restore. The best backup media is a USB disk.
We are not sure that splitting is the actual cause of the failure or whether something interrupted the backup and threw off the naming (like it happens sometimes during consolidation).
Pat,
I'm doing a clean backup right now. I "removed" other backups but have them as a redundant point. I decided to look up the relevant KB per your comment.
I believe that I did exactly what this KB told me not to do:
http://kb.acronis.com/content/21209
I moved my Acronis backup files from my "new" directory to my "old" directory. When Acronis went to create a new backup it, as stated in the KB:
(!) Always delete Acronis True Image backup archives via the product interface. Deleting backups directly from Windows Explorer may lead to inconsistency in the My backups list.
So far this backup is going smoothly and is named what I called it without any modifications or additions to the file names (sans numbering of course). When it is done I am going to delete the old backup, copy the current backup to the old location and then do an additional backup and let Acronis do all of the managing it wants to see if the problem recurs.
First backup done and created successfully.
Second backup done and created successfully... BUT it has the first TIB file misnamed:
========================================
M:\Acronis New System>dir
Volume in drive M is Misc
Volume Serial Number is 627F-DB2A
Directory of M:\Acronis New System
07/24/2011 07:12 PM .
07/24/2011 07:12 PM ..
07/24/2011 06:54 PM 734,003,200 Vista_(C).tib_A8AB0908-D15A-4B22-9472-EEF640E98DF51.tib
07/24/2011 06:58 PM 734,003,200 Vista_(C)10.tib
07/24/2011 06:59 PM 734,003,200 Vista_(C)11.tib
07/24/2011 07:00 PM 734,003,200 Vista_(C)12.tib
07/24/2011 07:00 PM 734,003,200 Vista_(C)13.tib
07/24/2011 07:01 PM 734,003,200 Vista_(C)14.tib
07/24/2011 07:01 PM 734,003,200 Vista_(C)15.tib
07/24/2011 07:02 PM 734,003,200 Vista_(C)16.tib
07/24/2011 07:02 PM 734,003,200 Vista_(C)17.tib
07/24/2011 07:03 PM 734,003,200 Vista_(C)18.tib
07/24/2011 07:03 PM 734,003,200 Vista_(C)19.tib
07/24/2011 06:54 PM 734,003,200 Vista_(C)2.tib
07/24/2011 07:04 PM 734,003,200 Vista_(C)20.tib
07/24/2011 07:04 PM 734,003,200 Vista_(C)21.tib
07/24/2011 07:04 PM 734,003,200 Vista_(C)22.tib
07/24/2011 07:05 PM 734,003,200 Vista_(C)23.tib
07/24/2011 07:05 PM 734,003,200 Vista_(C)24.tib
07/24/2011 07:06 PM 734,003,200 Vista_(C)25.tib
07/24/2011 07:06 PM 734,003,200 Vista_(C)26.tib
07/24/2011 07:06 PM 734,003,200 Vista_(C)27.tib
07/24/2011 07:07 PM 734,003,200 Vista_(C)28.tib
07/24/2011 07:07 PM 734,003,200 Vista_(C)29.tib
07/24/2011 06:55 PM 734,003,200 Vista_(C)3.tib
07/24/2011 07:07 PM 734,003,200 Vista_(C)30.tib
07/24/2011 07:08 PM 734,003,200 Vista_(C)31.tib
07/24/2011 07:09 PM 734,003,200 Vista_(C)32.tib
07/24/2011 07:09 PM 734,003,200 Vista_(C)33.tib
07/24/2011 07:09 PM 734,003,200 Vista_(C)34.tib
07/24/2011 07:10 PM 734,003,200 Vista_(C)35.tib
07/24/2011 07:10 PM 734,003,200 Vista_(C)36.tib
07/24/2011 07:11 PM 734,003,200 Vista_(C)37.tib
07/24/2011 07:11 PM 734,003,200 Vista_(C)38.tib
07/24/2011 07:11 PM 734,003,200 Vista_(C)39.tib
07/24/2011 06:56 PM 734,003,200 Vista_(C)4.tib
07/24/2011 07:12 PM 734,003,200 Vista_(C)40.tib
07/24/2011 07:12 PM 734,003,200 Vista_(C)41.tib
07/24/2011 07:12 PM 734,003,200 Vista_(C)42.tib
07/24/2011 07:12 PM 270,915,072 Vista_(C)43.tib
07/24/2011 06:56 PM 734,003,200 Vista_(C)5.tib
07/24/2011 06:56 PM 734,003,200 Vista_(C)6.tib
07/24/2011 06:57 PM 734,003,200 Vista_(C)7.tib
07/24/2011 06:57 PM 734,003,200 Vista_(C)8.tib
07/24/2011 06:58 PM 734,003,200 Vista_(C)9.tib
43 File(s) 31,099,049,472 bytes
2 Dir(s) 462,731,550,720 bytes free
M:\Acronis New System>
========================================
I'm going to go out on a limb here and guess that if I do not rename the first file that the next backup will append more characters the the end of the first file and all subsequent files.
I may have to update my support as it lapsed on May 14th, 2011.
Do not rename the files manually. That will create issues for ATI.
Do not worry about the names. The following backups look good. Validate each backup and you should be good to go.
Validation is part of my backup process. I have a few levels of data redundancy.
1) My data exists on my PC. That is not a backup.
2) My data also exists on a 2TB eSATA drive. I sync my system using Robocopy.
3) My data also exists on a 3TB FreeNAS box. I sync that with WinSPC's command line scp tool. For additional safety my CIFS mount point is read only on purpose in the rare event something tragic happens and a virus/trojan/malware decides to corrupt everything. Yes, I monitor my logs for issues.
I prefer to automate and let things just go. I did that but I noticed in my logs that the Acronis file names kept getting larger. Now I have a few choices.
1) Manually rename the large file so that they longer file name doesn't propagate to the next backup set. This goes directly against your advice. I need to verify that the longer filename grows from backup to backup. If not I'll just have to deal with a nonstandard filename. If it does persist...
2) Purchase support and hope that they can resolve this issue.
Thanks for your insight. I really do appreciate it.
Kevin,
If you copy files, verify the copy is identical to the original or validate the copy with ATI. We have seen a simple copy corrupt an archive.
Pat,
Thanks for the warning on archive corruption. I fully understand the consequences of a bad sector on a hard drive causing that to happen. MD5summer FTW:
http://www.md5summer.org/
So I decided to do a complete uninstall of Acronis. I rebooted my machine (per it's instructions), looked in the typical locations for Acronis files that might be left behind:
C:\ProgramData\Acronis
C:\Program Files (x86)\Common Files\Acronis
C:\Windows\Temp
C:\Users\Kevin\AppData\Local\Temp
I also deleted my Acronis backup from my main Acronis backup directory. I scoured the registry for all occurrences of Acronis, deleted them and then rebooted a second time.
I installed Acronis from the latest update (ATI2011.6868_s_en.msi) and then rebooted a third time.
Acronis found a VM that it wanted to convert (VirtualPC with Win98SE inside of it) and both my secondary and tertiary backups. I removed them all from the list as you directed above.
Before doing a backup I made copies of the following directories:
C:\ProgramData\Acronis
C:\Program Files (x86)\Common Files\Acronis
There were a few files locked but that is unavoidable in this instance. I then proceeded to recreate my original backup scheme.
The first backup was created correctly and was properly named. Part of my backup is to verify the backup upon completion. It validated correctly.
The second backup did the standard and expected longer file name so that if there was a problem you wouldn't have two partial backups in the same directory due to files being overwritten.
When the backup stopped and the validation process began all of the files were renamed and overwritten properly except for the initial one which had the long name still attached to it.
Please let me know if I have not followed a rational or proper uninstall, clean, reinstall and reconfiguration procedure. If I overlooked anything or performed an action incorrectly I need to know.
Thank you again for your continued patience.
Kevin
Kevin,
You have done the right things. It looks like you are facing a bug in ATI where it doesn't rename properly all the files that it has created. As long as the backup validates properly and the chains get created/replace properly, don't worry about the TIB names.
For extra testing, you could try to restore to a spare disk (you would have to put it inside the computer where the real disk is): that is the ultimate way to test a backup.
1) Do I have to purchase support to file a bug? I am loathe to purchase support, go through the support process, be informed that this will be fixed later and still have a product that doesn't function as I wish it to.
2) The only reason that I am worrying about the file names is that they get progressively longer as I perform additional backups. At a certain point the files will not be able to be created when the filename reaches 255 characters.
3) Restoring to a spare disk isn't an option at this time. I do have multiple disks with which to do this on hand.
I may revert to an earlier version of ATI as I do not recall the initial version of ATI 2011 having this issue.
1) Yes. If this is declared a bug, Acronis will reimburse you.
2) From your post #10, it looks like your following incremental/partials are looking good. So you are saying when you have a new backup chain that starts, you have the wrong name again? If this is the case, you might want to try Chain2Gen. This will move the existing backup away for retention and maybe avoid the file name problem. Or you can try to backup without splitting...
Pat,
Thanks for the update on paid support. I may get that going soon.
I have never used incremental/partials. I have always used full backups. I am unsure why my backups are appearing to look like incremental backups even after a clean installation.
I never use splitting so I am not sure how it behaves. I thought that when a backup is split, the pieces were put in a folder.
I guessed this chain is your first incremental/differential (a 2 is appended to the name) then split in pieces (20, 21, ...).
07/24/2011 06:54 PM 734,003,200 Vista_(C)2.tib
07/24/2011 07:04 PM 734,003,200 Vista_(C)20.tib
07/24/2011 07:04 PM 734,003,200 Vista_(C)21.tib
07/24/2011 07:04 PM 734,003,200 Vista_(C)22.tib
07/24/2011 07:05 PM 734,003,200 Vista_(C)23.tib
07/24/2011 07:05 PM 734,003,200 Vista_(C)24.tib
07/24/2011 07:06 PM 734,003,200 Vista_(C)25.tib
07/24/2011 07:06 PM 734,003,200 Vista_(C)26.tib
07/24/2011 07:06 PM 734,003,200 Vista_(C)27.tib
07/24/2011 07:07 PM 734,003,200 Vista_(C)28.tib
07/24/2011 07:07 PM 734,003,200 Vista_(C)29.tib
Let's try a custom backup scheme:
- full backup,
- store no more than 1 most recent version
Pat,
I'll do that when I get home.
You said:
I thought that when a backup is split, the pieces were put in a folder.
Correct. They are all named properly when they are split. I use 700MB (CD) sized chunks rather than one 25.3GB file.
You said:
I guessed this chain is your first incremental/differential (a 2 is appended to the name) then split in pieces (20, 21, ...).
If you look at the full list above you will see that it has a total of 43 700MB files. That is one full backup of my 1TB C drive. Not incremental/differential. Let me put them in the order they were created rather than sorted by name:
Vista_(C).tib_A8AB0908-D15A-4B22-9472-EEF640E98DF51.tib
Vista_(C)2.tib
Vista_(C)3.tib
Vista_(C)4.tib
Vista_(C)5.tib
Vista_(C)6.tib
Vista_(C)7.tib
Vista_(C)8.tib
Vista_(C)9.tib
Vista_(C)10.tib
Vista_(C)11.tib
Vista_(C)12.tib
Vista_(C)13.tib
Vista_(C)14.tib
Vista_(C)15.tib
Vista_(C)16.tib
Vista_(C)17.tib
Vista_(C)18.tib
Vista_(C)19.tib
Vista_(C)20.tib
Vista_(C)21.tib
Vista_(C)22.tib
Vista_(C)23.tib
Vista_(C)24.tib
Vista_(C)25.tib
Vista_(C)26.tib
Vista_(C)27.tib
Vista_(C)28.tib
Vista_(C)29.tib
Vista_(C)30.tib
Vista_(C)31.tib
Vista_(C)32.tib
Vista_(C)33.tib
Vista_(C)34.tib
Vista_(C)35.tib
Vista_(C)36.tib
Vista_(C)37.tib
Vista_(C)38.tib
Vista_(C)39.tib
Vista_(C)40.tib
Vista_(C)41.tib
Vista_(C)42.tib
Vista_(C)43.tib
This file is misnamed when the full backup is ran a 2nd time:
Vista_(C).tib_A8AB0908-D15A-4B22-9472-EEF640E98DF51.tib
It should be named this:
Vista_(C).1.tib
As it is on the first pass.
On the third pass Acronis takes the name of the first backup
Vista_(C).tib_A8AB0908-D15A-4B22-9472-EEF640E98DF51.tib
And makes the new series of backup files look like what I wrote in post #3. It just keeps appending based upon the name of the first file. When the first file is made on the first pass it is done correctly. When the second pass goes it, rightly so, appends an alphanumeric string to differentiate itself from the previous backup in the same directory.
It is my assumption (and I could be way off base here) is that when the backup is finished that the old backup is deleted (this happens) and that ALL of the new files with the alphanumeric strings are renamed to what the original was.
I think that I'll disable automatic verification on the backup. I have a feeling that Acronis (while backing up) may not be releasing it's file lock fast enough before the Acronis verification process starts. If they overlap this may explain the failure to rename issue that I am experiencing.
Just to make sure I follow procedure correct.
1) Remove my current backup scheme.
2) Remove all Acronis Backups from my machine (I still have them on my external hard drive and FreeNAS box).
3) Create one full backup (I exclude my data directories). The one backup will be broken up into 700MB .tib files.
4) I will do one backup without verification at the end.
5) I will then do the same backup.
Let me know if all of this makes sense or not.
Thank you for clarifying the naming sequence, this makes sense.
Good idea with the verification, worth trying. But then things like virus scanning and indexing might be candidates as well for other processes locking the files.
It is possible that ATI's renaming issue worsens because the previous files are still there. If you complete your backup, then manually move all the files to another folder before the new backup, you might avoid the aggregation issue, although the first file might still be wrong. Chain2Gen can automate the moving for you.
I will totally look into Chain2gen when I get home. Thank you.
Disabling verification on my backups did not work. I'm going to revert to an earlier version of ATI and see if that resolves my issue.
Kevin,
RE: Chain2Gen (C2G)
If it is our intention to split your backup into multi small files, C2G will only work for you if each backup is a full backup.
C2G is geared to a single file backup but may work in that each backup will be in its own folder (set0, set1, set2, etc) and each folder will comprise whatever files are created for that specific full backup--whatever the number of files.
Your file naming issue will continue as C2G has no control over the backup file names. Each full backup will be to an empty folder and as the movement of files was not done by TI so the file name issue may be a little different.
If you have the time, go ahead and set up C2G based on the above.
Edit: My reason for responding is your post #22 so you would know what to expect from C2G. C2G runs at the first stage of the task before the backup actually begins. If the number of files in the set0 folder meet or exceed the user set parameter file, C2G empties (rotates into history) the contents of the Set0 folder so that TI will encounter an empty backup folder.
When a backup file is broken into pieces and later copied onto another media, in order for a file or backup to be recovered, the entire backup would need to be copied back so all files exist in a single folder. If during the burn and copy back any of the files becomes corrupt, then the entire backup becomes useless. Whether C2G would work successfully (rotate set0 into history) would depend on how well the user is able to set the count for the set0 folder. C2G has no control over the file name.
GroverH,
I'm working on one thing at a time right now. I did an uninstall of my current version of ATI 2011, rebooted, cleaned out temp files, went through my registry, deleted everything that I could read this thread, downloaded PsTools, opened up an administrative command prompt, changed directories to the directory that I extracted PsExec in and ran the following command to get the registry to open up with the system account:
psexec -s -i -d regedit.exe
Found the keys, deleted them and rebooted.
I installed ATIH2011_6597_en-US.exe instead of the latest version to see if this issue is related to an update.
I did a defrag of all of my disks last night using Raxco Perfect disk, did an offline defrag of the files it couldn't do when Windows was running.
When I get home tonight I will be, once again, testing to see if my backup works as I expect it to.
I have reverted from ATI 2011 to ATI 11 as both of the versions of ATI 2011 that I tried all replicate the issue on my system. ATI 11 is fully supported for working on my system and I have yet to experience an issue with names changing.
Thank you all for your time on this issue. I am deeply appreciative.
Kevin
Kevin,
Were you using the Single Version Scheme?
Pat,
Yes. Single version scheme.
I think there could be a bug with the single version scheme. You should try a custom scheme, full, keep only 1 most recent version.
See similar thread here:
Thanks. I'm glad(?) that I'm not alone.
I'm going to stick with ATI 11 until ATI 2011 is patched or the issue is resolved.
There are some threads of other people that seem to be affected by either the same or similar issue.
15371: Backup filename grows and grows and grows and grows
Per the 17914 thread[also linked above] it appeared in the beta for ATI 2011.
I am hopeful that someone from Acronis can address this issue soon. Rumor has it that they occasionally stop in to check things out.
I do server support for my day job. I fully understand and respect the difficult decisions that management has to do when triaging impacting bugs. Every bug found puts an additional burden on the QA department for at least two cycles and perhaps more. I am cautiously optimistic that this issue can be resolved in the next update.