My understanding for the past decade has been that retention was associated with the job. That is, I configured it in the job. I was not aware of any backup chain that, apart from a job, somehow had retention associated with it. For example, in the job I configured 14 days or 30 days or 90 days. There was never any mechanism to configure retention through a chain. Therefore, logically speaking, there was a relationship between the job and retention, not the chain and retention. Of course, I am aware of the other features that came into existence related to SOBR and tiering and such, and the necessity of background retention processes that would run independently of those jobs, perhaps based on settings on the repository itself. However, as it stands now, even in v12, I do not configure retention on a simple SMB repository. I do not configure retention on the chain itself. I configure retention in the job. And historically, retention always took place after the job ran. So it really makes no sense to me at all why Veeam's background retention process would extend to include a regular VM backup job that has been deleted intentionally, resulting in an orphaned backup set. At least, this kind of behavior should not be the default because it's considered a "destructive action" that results in the loss of backups. Speaking of loss of backups, another behavior that I became accustomed to over the decade of experience was that Veeam would never automatically retention the last backup in a chain. If a VM, for example, no longer existed and therefore wasn't being backed up in a job, the retention would continue against that VM until the last point which Veeam would safeguard, requiring manual cleanup. I thought this was a very good design and touted it as much to my clients. Yet, this recent experience was the TOTAL loss of the entire orphaned backup set.
Thank you in advance for any explanation or clarification!
