Retention points not honored after moving vm to new job

[squebel]

Hello,

We are shuffling some backups around and for one reason or another we are creating new jobs for some vm's and then excluding those vm's from their original job. The original job, which is a Forever Forward Incremental, is set to retain 7 restore points yet after each run (once per day), the merge operation is dropping a restore point for that vm in the original job. I did not think it would do this. I thought that the 7 restore points for that vm would stay in the original chain but would just get older and eventually need to be manually purged. Can someone explain why this is happening and if there is any way to avoid it?

[PetrM]

Hello,

It is by design: a job represents a set of settings applied to the added objects, and retention policy is just one of such settings. If there are more than 7 restore points for a VM, merge operation will inject the first incremental point into the full one. But why do you need to avoid it?

Thanks!

[squebel]

I understand how the retention works when you keep taking backups of a vm but as I said, we stopped taking backups of that vm in that job. Why is it merging the restore points into the full and allowing that vm to have less restore points than what the job says should be there?

I want it to stop doing this because the storage the backups are on is i/o bound right now and these unnecessary merge operations are creating huge amount of random read/write i/o that the array is having a hard time keeping up with. The new jobs were created to force active fulls and new chains onto new storage.

[PetrM]

Why is it merging the restore points into the full and allowing that vm to have less restore points than what the job says should be there?

Now, I'm getting it. Can you please open a support request and ask our engineers to explain the behavior? Also, please share a support case ID so that I can keep an eye on it.

Thanks!

[squebel]

Case 05735187 has been opened

[foggy]

Looks like deleted VMs retention is in action.

[squebel]

I wondered about that. So, from the documentation, I see this:

Veeam Backup & Replication checks if any machine in the backup meets the following conditions:

There are no successful backups for the machine for the last N days.

There are no corrupted backups for the machine for the last N days.

Where N is the number of days specified in the Remove deleted items data after N days setting.

I do have the setting set on the original job to 7 days. It has only been 2 days since the vm was removed from that job and moved to a different job. If I understand the doc properly, it should delete data only after the 7th day of that vm not being backed up. Or am I not understanding?

[foggy]

Your understanding is correct. Provided the affected VMs were backed up during the last 7 days, deleted VMs retention shouldn't come into action. Let's see what our support team says after reviewing the setup closer.

[squebel]

I set the "Remove Deleted after" to 15 days yesterday on the job that keeps 7 days of restore points. The job ran last night and still decided to roll up restore points and throw one away even though it has definitely been way less than 15 days since the vm in question was backed up in that job.

[squebel]

Support got back to me on this and here's the explanation:

Despite the number of days not being met the chain still is having normal retention ran on it. The behavior is expected solely because that's how the per vm chains work as of now. He did note that in v12 the chains will be truly "per vm" chains. I noted the settings and the chain setup and he did note that it is expected even though the vm is excluded.

So, I guess if you don't want it to violate the retention policy for an individual vm's backup, don't use the "Delete after X days" option. Seems to be the only option at this time. Which also means the documentation is wrong.