Backup copy jobs have more restore points than configured (for 2 out of 3 jobs)

[kjstech]

We have 3 Backup jobs, an fs1, fs2, fs3 each containing a group of VMware vms. They do an active full on Saturday and the job is configured to keep 7 restore points. Right now fs1 has 10, fs2 has 12 and fs3 has 13 restore points.
We have 3 weekly backup copy jobs set to periodic copy (pruning) - it's the only "illuminated option" selectable, and copy every 7 days starting at 1 am. In target, it says restore points to keep: 8. Keep the following restore points as full backups for archival purposes (4 weekly Sundays) and 0 for the rest of the options. Finally Read the entire restore point from source backup instead of synthesizing it from increments is selected.

Here's the issue, weekly backup copy job fs1 has 22 restore points for all but 1 VM (that 1 VM has 6). (way too many for me)
weekly backup copy job fs2 has 6 restore points for all vms in it (looks good to me).
weekly backup copy job fs3 has 23 restore points for all vms in it and 22 restore points for one of the vm's in it (way too many for me)

We thought this past Tuesday after they completed that the oldest restore points would have automatically gotten wiped out. If I do properties on that weekly fs3 job I see a full on 1/15, 1/8, 1/1, 12/25, 12/19 - that right there is 5 fulls, then prior to that date we didn't have it set to active full and we have increments from 12/11 down to 5/5, and then a full on 4/20/2020. I want everything prior to 12/19 deleted. How can I do that? Both boxes forget and remove from disk are greyed out.

They write to an Exagrid appliance.

Thanks for your help.

[Gostev]

Hello! Since you're posting about a technical issue, please include the corresponding Veeam support case ID, as requested when you click New Topic. Thanks!

[foggy]

Finally Read the entire restore point from source backup instead of synthesizing it from increments is selected.

With this setting enabled, the backup copy effectively switches to the regular forward incremental mode so having more restore points on disk than the configured retention implies is expected. However, the older part of the chain looks too far behind, I'd ask our engineers to take a closer look at why those have not been deleted.

[kjstech]

I just opened Case #04602998 on this issue. I have been working with our Exagrid support rep on cleanup and we have made improvements in the last month but these backup copy jobs just keep hanging onto a full in April last year and dozens and dozens of incrementals between April and December.

[foggy]

Sounds strange, there could be something that prevented deletion of that part of the chain, logs should tell.