Chain too long after adding synthetic fulls

[kappa85]

Hi, I am on last version but I think it's a general question. I have a backup job with forever forward incremental, the job runs every hour from 7AM to 10PM and we retain 42 RP (14 RP a day, so 3 days of hourly backups, it's a unique small VM). Then I decided to add synthetic fulls once a week (friday) to test a tape job configuration, after three weeks the result is that the chain on disk is made of 80+ RP, 2 of them are full backups. So, I cannot understand where 42RP setting applies since a single chain (synthetic full + incrementals until the next synthetic full) is longer than 42 RP. At the moment for this job I have on disk:
- today's synthetic full (7AM, first backup of the day) + hourly incrementals until now
- previous synthetic full (last friday, 06/24) + hourly incrementals up to 06/30 11PM (the last incremental after today's synthetic full)
These are 80+ RP. The prevoius chain started on 06/17 and ended on 06/23 has been deleted, but I didn't see when and, most of all, I can't understand the logic that applies there.

[Shestakov]

Hi,
That`s an expected behavior, because if the older chain get deleted you will have less than 42 RPs what is the retention policy violation. So VBR waits until you have 42 RPs in the newest chain to delete the older ones.
Having periodic full backups you have to deal with 2 .vbks
Why have you changed forever incremental method by the way? It also supports tape backups.
Thanks!

[kappa85]

So VBR waits until you have 42 RPs in the newest chain to delete the older ones.

This seems not true because between the older .vbk and the one created today, I have 77 incrementals.
EDIT: ok, I understand. It will wait for the new chain to have 42 RP and then will delete the old one. Correct? I hoped it deleted only RP exceeding 42, instead it keeps the complete chain...

Having periodic full backups you have to deal with 2 .vbks
Why have you changed forever incremental method by the way? It also supports tape backups.

I configured a "standard" tape job with process incrementals and a GFS tape job for monthly and yearly only. With this setup, on tape I find all incrementals of the chain, I was trying to say "write a full just before starting a new media set so the chain on tape will be this full + following incrementals, ignoring previous incrementals you find on disk"... is that a bad idea?

[Shestakov]

This seems not true because between the older .vbk and the one created today, I have 77 incrementals.
EDIT: ok, I understand. It will wait for the new chain to have 42 RP and then will delete the old one. Correct? I hoped it deleted only RP exceeding 42, instead it keeps the complete chain...

That`s correct.

I configured a "standard" tape job with process incrementals and a GFS tape job for monthly and yearly only. With this setup, on tape I find all incrementals of the chain, I was trying to say "write a full just before starting a new media set so the chain on tape will be this full + following incrementals, ignoring previous incrementals you find on disk"... is that a bad idea?

Not 100% sure I`ve seized your goal. You want to write in tapes both historical(GFS) and basic backups. You can accomplish the second both using forever-forward and simple incremental as a source job.
Thanks!

[kappa85]

Yes, that could work if backup jobs have one week of retention. Since I have jobs with 2-3 weeks of retention, each week my tape job will write all incrementals of chain, while I'd like to have only the last week. This is why I was trying with synthetic fulls (to "interrupt" the chain).

[Shestakov]

I see your point.
By the way you can leverage Transforming Incremental Backup Chains into Reverse Incremental Backup Chains option to have only 1 full backup and get older increments deleted,