Feature Request: Veeam not violate retention policy for VMs removed from job

[ma-strs]

I have a Forward Incremental backup job with weekly synthetic fulls, 15 retention points and per VM backup files. The backup runs 6 days a week. This results in each VM having 15 restore points growing up to 21 restore points and back down to 15 restore points. This is expected behavior.
The problem I'm experiencing is when a VM is removed from the backup job, over the period of three weeks all its backup chains get deleted (except any GFS points). I opened case #05764249 with Veeam and Veeam Support indicated that this was designed behavior.
I believe this is flawed logic in the product. Veeam should never delete restore points violating the retention. This should only be done if the "Remove deleted items data after" option is selected, or manually by the user.
I am requesting Veeam change this behavior to freeze the backups for a removed VM where they are if removing the oldest backup chain will violate the retention points setting. Veeam shouldn't arbitrarily remove backups of VMs no longer in the backup job just because there is at least one VM in the job whose oldest chain is eligible for deletion.

[Gostev]

Unfortunately we can hardly change this behavior because it has been in the product since the inception and is something our customers actually want and rely upon. For example, it is a very common workaround in case of large job reorgs to remove all VMs from the job but keep a single "dummy VM" to let the job continue running and applying the restore point based retention policy until all restore points are deleted.

What you are proposing is plain unmanageable in larger environments where VMs appear and disappear every day. Customers do expect backups of any deleted VMs to age out and be deleted according to the retention policy, thus releasing the repository disk space for backups of any new VMs... you are literally the first person in 15 years to request this NOT to happen. Understandably so, as tracking and removing backups of deleted VMs manually means much on-going management, no possibility to have a "set and forget" solution (as eventually you will face overfilled backup repositories with no space for new backups), and so on and so forth.

Have you considered copying the particular VM's backup files aside before or shortly after deleting the VM? In your proposal, you suggested backups should be removed manually by the user. Copying them aside manually is basically an identical suggestion.

There's a small chance there could be some registry hacks for dev/test purposes to control the clean up in such scenario but I'm not sure... someone will need to talk to the devs and see if anything like this exists in the current version.

Overall, the longer-term recommendation is to move to time-based retention policy from restore point-based, as the former is "cleaner" and much more standard for backups. Restore-point based retention is in the product due to replication jobs, which we had since V1... and it's not a default setting.

P.S. "Remove deleted items data after" feature is not related to the job's retention policy, it's rather perpendicular to it. Its function is to zero out blocks belonging to deleted VMs in forever-transformed multi-VM full backup files, making them reusable for new data. It's a very legacy functionality as few customers use transform functionality and non-per-VM backup files these days. @HannesK I think we should really plan on removing more of this legacy stuff in V13