I have history with Veeam from version 7 through 12 that spans almost 9 1/2 years. But only the last year of that time covers v12, so I admittedly have less experience with this version than all the ones I supported through my employment. At the end of 2023, I changed employment and didn't have much to do with Veeam until this past month when I deployed it for a small client. Imagine my surprise when the "orphaned" backup set of the old server vanished after a week. Investigation led me to background retention which apparently affected these types of chains as of v12. I had no idea. Had I known, I would have created an Export of the latest point to be stored outside of any kind of retention process. What is done is done. Thankfully, we do have the old server, with data and programs, so I can take another backup of it. My reason for posting here is to understand Veeam's reasoning behind this. Let me first present my reasoning.
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!![:)]( "Smile")
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!
Statistics: Posted by TitaniumCoder477 — Apr 02, 2025 4:51 pm
![Madonna – Who’s That Girl (1987/2020) [FLAC 24bit/192kHz]](http://imghd.xyz/images/2023/06/08/0093624951148_6004dceff9e1db710a9.jpg)
![VA – DVD-Audio Music Sampler Vol.2 (2003) [DVD-Audio ISO]](http://imghd.xyz/images/2026/05/13/4lSo1rN.jpg)
