Something about retention policy isn't clear

[kikker05]

The documentation is quite clear on what happens when incrementals and full versions fall off the retention policy and become pruned by means of either deletion, merging in order to keep the chain intact, or a combination depending on the policy.

However, imagine the simple scenario where a monthly full backup and daily incrementals are scheduled with both full and incrementals retained for 3 months each.
My question is what happens at the beginning of the "fourth" month when the first full backup expires?  Does this first full backup get merged with the first incremental, and then merging takes place each day to scoop up the incremental created the following day (3 months ago)?   A merge each day sounds a bit absurd and resource costly, so I can imagine something else happens instead.

[Froggie]

When a FULL is discarded, all of its child dependencies (DIFF & INC) are discarded as well. What will remain will be FULL #2 & #3 (and all their dependencies) and the new FULL #4.

In your scenario, no INC retention or merging is even required, they will be pruned by the 3-mo FULL retention schedule.

[kikker05]

Ok thank you - that makes sense.  I think where I (and others) may be hung up on is the fact that the retention policies for Full, Incremental, and Differential are able to float freely and independently from one another, which according to my understanding should not be possible.

In the above example of monthly full backups and daily incremental backups (so two lines added in the schedules window), how is it possible for a user to set the Incremental retention period to a duration longer than what is set for the Full retention?  (An Incremental based on a Full can never outlast that Full backup).

On a different note, may I suggest implementing an option for an auto "Smart backup retention" - There would remain one backup for each of the last 7 days, one for each of the last 4 weeks, and one for each of the last 12 months.  I think this could be accomplished with daily incremental backups (7 day retention), weekly differential (4 week retention), and monthly full (12 months retention).

[al3x]

In the above example of monthly full backups and daily incremental backups (so two lines added in the schedules window), how is it possible for a user to set the Incremental retention period to a duration longer than what is set for the Full retention?  (An Incremental based on a Full can never outlast that Full backup).

Well, there's always the possibility of manual or additional backups. So for example if you only want to retain 30 incremental backups but you additionally do manual incremental backups or maybe event triggered ones like on Windows boot. Then you might end up with an undefined number of additional incremental backups, based on how often you restart your PC or how often you decided to do manual backups in the last month.

So maybe in that case you might want to set a cap for inc. backups of e.g. 50, even though you would only reach 30 in a month initially.
It all depends on what you want to keep and how you set up your backup schedules. 

*Edit: Ah, nevermind, I think I misread your question. I first thought you might question why there's a possibility of setting a higher inc. value than what you actually backup with the schedule, sorry  - or did you actually mean that? I'm confused, haha 

[Froggie]

Ok thank you - that makes sense.  I think where I (and others) may be hung up on is the fact that the retention policies for Full, Incremental, and Differential are able to float freely and independently from one another, which according to my understanding should not be possible.

In the above example of monthly full backups and daily incremental backups (so two lines added in the schedules window), how is it possible for a user to set the Incremental retention period to a duration longer than what is set for the Full retention?  (An Incremental based on a Full can never outlast that Full backup).

On a different note, may I suggest implementing an option for an auto "Smart backup retention" - There would remain one backup for each of the last 7 days, one for each of the last 4 weeks, and one for each of the last 12 months.  I think this could be accomplished with daily incremental backups (7 day retention), weekly differential (4 week retention), and monthly full (12 months retention).

I guess there are rules for "child" dependencies that the Devs expect the user to understand when it comes to GFS (Grandfather, Father, Son) retention schemes.  Your suggestion for "Smart Backup Retention" is fine, but very few users will use what you suggest... too much storage (12-fulls... <Yikes!>).  That's why they let you select what works for you.  Personally, I use the following retention scheme... Full=2mo (1/month scheduled), Incremental=7days (12/day scheduled = 84).  I allow the weekly DIFFs (1/week scheduled) to accumulate over the 2-mo period and let then prune with the FULLs.  My System doesn't need anything older than that.  I use "days" and "months" because I also use HBS as a snapshot/rollback System as well, allowing me to take many asynchronous (manual/unscheduled) images as needed.  I do this when doing questionable software testing, Windows updates/upgrades, visiting questionable web sites and when I'm using the System as a HoneyPot for "badies" in the wild... a very useful feature.

Each user will have very different requirements.

[al3x]

Each user will have very different requirements.

True! For example I backup to my Synology NAS on a daily basis.

So that's one week of inc. backups, weekly differential backups and monthly full backups. Retention is set to keep 2 differential backups and 1 full.
Additionally the NAS has snapshot replication set to 7 days, so everything that got deleted by HBS is still kept for another 7 days.

I don't think such individual settings would fit in a preset 

[Froggie]

Agreed...