Too Many Large Splits
Environment: Win10, True Image 2018
Backup Source: 1.44TB folder
Backup Target: 6TB USB Drive, formatted NTFS
Backup Method: Incremental, 2 full versions, Store no more than 2 recent version chains
Backup Splitting: Automatic
Given the following files: (also see image attached)
02/10/2019 12:47 PM 1,292,046,958,592 iTunes Library_full_b22_s1_v1.tib
03/03/2019 02:07 PM 1,491,859,406,848 iTunes Library_full_b22_s1_v1-2.tib
03/25/2019 07:24 AM 1,569,009,901,568 iTunes Library_full_b22_s1_v1-3.tib
03/27/2019 02:03 AM 906,506,240 iTunes Library_inc_b22_s2_v1.tib
03/31/2019 02:02 AM 29,241,344 iTunes Library_inc_b22_s3_v1.tib
Questions:
1) What are the "vn-n" files? Best I can tell from the 2nd post on this thread from Mark is that they are Volume Backup Splits (though that post is in the TI 2017 forum area). Are splits required for NTFS?
2) If they are splits, why is each one about the size of the Backup Source folder or more (shouldn't they be a fraction of the source size)?
3) If they aren't splits, what are they?
4) Regardless of what they are, can I keep this from happening so I don't have to get an even larger target drive? And still have 2 backups?
Note: I have 2 other TI backups going to the same drive, but they take up less than 800GB combined / all told
Thanks, Chris
Thanks Steve,
I will use the tool and will nuke such files in the future with confidence now.
But I'm not sure why there would be a file of the exact same name if managing the filenames by incrementing the chain / version parts of the file name. Can you say what conditions cause this to happen, so I can avoid that?
Chris
02/10/2019 12:47 PM 1,292,046,958,592 iTunes Library_full_b22_s1_v1.tib
03/03/2019 02:07 PM 1,491,859,406,848 iTunes Library_full_b22_s1_v1-2.tib
03/25/2019 07:24 AM 1,569,009,901,568 iTunes Library_full_b22_s1_v1-3.tib
03/27/2019 02:03 AM 906,506,240 iTunes Library_inc_b22_s2_v1.tib
03/31/2019 02:02 AM 29,241,344 iTunes Library_inc_b22_s3_v1.tib
Chris, difficult to say why you ended up with 3 x the full_b22_s1 backup files, but the chain looks to be continuing with the 2 latest incremental files (based on the v1-3.tib full file).
One possible cause can be if you have restored your computer at some point between 02/10 and 03/03 and again between 03/03 and 03/25, as that type of action could cause information about the backup (held in an internal database) to be reset to an earlier point before the b22 chain was started?
Perhaps it was just me nuking old versions from the file system (which might remove it from the HDD, but not the database), rather than use the clean up options within the tool. I'll try to do that in the future.
Thanks for your help!
Chris
Christopher Sherwood wrote:Perhaps it was just me nuking old versions from the file system (which might remove it from the HDD, but not the database), rather than use the clean up options within the tool. I'll try to do that in the future.
Thanks for your help!
Chris
Most likely. The Acronis database in Windows expects files it makes to be there and named exactly as it created them. When we manually modify the files (move, rename, delete) outside of Acronis, the database still expects them to be there because it doesn't know about the external changes made by the end-user.
When it comes to cleanup, best to use the Acronis GUI from within Windows. Otherwise, if you make manual changes, you need to "validate" the backup job in the GUI and then either point it to the modified file(s) or ignore each one that was deleted. And this is something you have to do for each .tib file in that backup that was modified outside of Acronis.
In the long run, usually easier/faster to just clean it up directly within Acronis while the backup job/task is still active in the console.