Auto Cleanup Not Working?
Hi, I've set up a custom backup scheme that includes auto-cleanup of version chains older than 60 days (I'm trying to set a two month history of backups). I recently ran close the limit on my destination drive and was expecting that the 60 day limit would have kicked in; however, the first month's backup chain did not get deleted. Any ideas why this is?
Here's the configured scheme: /system/files/users/194753/scheme.png
And here's the list of chains (backup files) on my destination drive: /system/files/users/194753/file_list.png
By my calculations (based on last night's backup date) the *_full_b4_s1_v1 file (dated 1/4/16) is older than 60days and should have been deleted. Any ideas as to why is wasn't?
Can I delete this file manually and then re-validate the backup in order to free up space and get the backups running again?
Thanks.

- Accedi per poter commentare

For the automatic cleanup function to work, all the images contained in a version chain need to satisfy the age criteria, so not just the *_full_b4_s1_v1 file but all the *_inc_b4_* files that comprise the same version chain. In your case, you will need the 8th incremental image to be over 60 days age before that version chain will be 'cleaned' and removed.
The date of your *_inc_b4_s8_v1 image file is only 29/01/2016 which is only 39 days old today.
- Accedi per poter commentare

Thanks Steve. I created and posted my response without knowing you were in he process of answering.
=================================================================
♦ Delete versions older than [defined period] (available for full method only) - Select this option to limit the age of backup versions. All versions that are older than the specified period will be automatically deleted.
♦ Delete version chains older than [defined period] (available for incremental and differential methods only) - Select this option to limit the age of backup version chains. The oldest version chain will be deleted only when the most recent backup version of this chain is older than the specified period. Refer user note 1:
======================================
My understanding/interpretation of older than 60 days is:
The timer began counting after the last file in the oldest chain was created.
Thus the control file is Inc_B4_S9_V1 created Feb 2, 11: 04pm. The file was older than 1 day on Feb 3 after 11:04 pm.
Feb2 was calendar day 33. Older than 60 days is scheduled to occur after calendar day 93 after 11:04 pm. on April 2.
Deletion will occur on the next backup AFTER 11:04pm whiich may be April 3.
After that, the next scheduled deletion will be after April 26 (calendar day 117) or 60 days after the creation time of Inc_B5_S9_v1 which was Feb 26. or calendr day 57
- Accedi per poter commentare

[Sorry for the late reply.]
Thanks, both of you, for identifying the key point that I was missing: "all the images contained in a version chain need to satisfy the age criteria". This makes total sense and I should have realized this (instead I was just counting from the oldest file's date, which obviously is the largest in the chain, and was hoping that this file would get deleted after 60d - but this would invalidate the whole chain, so it makes sense that only the most recent date in the chain is used as the compare date).
My follow-on question is whether (since there is no facility to do this from the ATI GUI, on a chain by chain basis) I can manually remove this oldest chain (b4_s1_v1 through b4_s9_v1) in Explorer and then "revalidate" the backup in ATI. Then I'd also reduce my history to 30d (from 60d) in the backup settings (is this also possible? somewhere I read that whenever you change these sorts of settings you need to create an entirely new backup definition, which seems odd...). Maybe I can just change the history range 30d and then the auto-cleanup will immediately delete old chain?
Thanks again for your help.
- Accedi per poter commentare

You can delete an older chain (full+its incrementals) manually, and then validate the remaining chains, yes.
Changing the cleanup rules in the middle of a backup chain can lead to unexpected results. It seems that sometimes the counting is reset at the time of change (true for the number of incrementals before the next full, for example), or leads to some "orphaned" chains that don't get deleted. This is why it is more predictable to move the existing backup files to another directory on the same volume, and create a new backup task.
- Accedi per poter commentare

OK, thx for this.
- Accedi per poter commentare

Hi again,
OK, so I created a new backup with what I thought were the correct scheme settings in order to get cleanup (i.e., deleting of older chains) working with the proper timeline. This is still not working :(.
Here's what I have for the scheme settings: /system/files/users/194753/scheme2.png
Here's the latest file list: /system/files/users/194753/file_list2.png
The oldest chain here is from 4/23, which is greater than 32days from today. Why wasn't this chain deleted after the last backup was run (on 5/30)? Are there not any logs that I can look at to see what ATI is trying to do here?
Thanks,
-David
- Accedi per poter commentare

David, for your 32 day rule to fire, the last incremental backup in the version chain has to satisfy the rule.
Entire PC (NEWT)_inc_b2_s6_v1 was created on 09/05/2016 and thus is only 24 days old as of today.
The age of the version chain is taken from the age of the last member of the chain, not the first.
- Accedi per poter commentare

;) [Groan], OK thx for clarifying, I'll get this right eventually!
- Accedi per poter commentare