Don't understand how immutable works with retention policy

[pufferdude]

I'm brand new to using Veeam Vault, and I have a simple job that backs up a VM directly to Veeam Vault. It appears to be working fine, but I'm struggling to understand what I'm seeing.

The vault itself has its immutability set to 30days, which is the minimum, and my job has its retention policy at 14 days.

My confusion arrises when I look at the properties of the backup under Backups | Object Storage | My Job. I see 15 restore points... the original full, then 14 incrementals. Every day the oldest incremental disappears and a new one is added for the most recent backup. I only started this on 2025-03-26 so I'm not 30 days in yet.

What I don't understand is how Veeam is "deleting" an incremental (the oldest) when the vault is immutable and the file that was deleted is still within the 30day immutabilty period. Are the old files really still "there" taking up space in the vault and Veeam's UI is just hiding them and waiting to delete them? Or am I completely not understanding how immutability works, or ? Or are my immutabuility period and retention period nonsensical in this setup?

Any insights appreciated.

[KirillChuxlancev]

You are correct, the incremental restore points outside of the retention policy are not physically deleted from Veeam Vault as they are made immutable for the configured immutability period. They are kept until the immutability expires and are cleaned up afterwards. The points are removed from the UI to match the desired retention settings. The chain of restore points can be reverted to the previous state to show the existing restore points in the UI if needed.

The immutability model (and revert feature) are described in this article - https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[pufferdude]

Thanks, that helps a lot.

The chain of restore points can be reverted to the previous state to show the existing restore points in the UI if needed.

Can you tell me how that's accomplished? (nevermind... just realized you pointed me there in the link)

Based in your info, it sounds to me like having a backup retention period < the 30day minimum immutability period is kinda pointless, and 30 days should really be the retention period for my job... If the space is being taken by restore points, might was well make them all useable... I think?

[KirillChuxlancev]

You are right — in general, retention settings that match the set immutability period is a correct configuration.

A note regarding Veeam Vault immutability: the feature is enabled by default and set to 30 days. However, the period is configurable and can be decreased if needed.

[KirillChuxlancev]

A small addition - all the points (both fulls and increments) outside of the retention policy will be removed from the UI.

[pufferdude]

Thanks!

[ericschott_OF]

You will want to monitor both the repository immutability (you are aware) and the GEN setting being used from registry for immutability

You can model both of these with this sizer:

https://objectfirst.com/backup-storage-calculator/

[pufferdude]

I think I'm still missing something obvious with the way this all works. I'm now WELL past my initial 30 days, and I have 31 restore points... each day the date on the full changes and there's a new incremental in the UI.

Today I'm seeing in the Veeam UI (when looking at the properties of the Job under Object Storage):
- Total Size: 443GB
- Backup Size: 515GB

But when I look at the Veeam Data Cloud Vault web portal, I see my storage is using 777GB out of my 1TB provisioned. It's as if nothing EVER gets deleted from the Vault, even when it's beyond the job retention period and the vault Immutibility period.

What am I missing? This thing appears that it will just incrementally grow "forever." Is there any easy way to see what's IN the vault itself?

[pufferdude]

Ok, I think I found the answer at https://helpcenter.veeam.com/docs/backu ... ml?ver=120 (posted above). Within, it says:

Apart from the immutability period set for each object storage repository, Veeam Backup & Replication automatically adds several days to the immutability expiration date to reduce I/O operations and associated costs. This period is called Block Generation. You do not have to configure it, the Block Generation setting is applied automatically. For more information, see Block Generation.

Therefore, the actual retention should be calculated according to the following formula:

Actual retention = job retention policy + immutability period + Block Generation period

This means that the job retention period gets ADDED to the immutability period AND a "block generation period" is also added... so in my own case the overall retention would be:

Job retention (30days) + immutability period (30 days) + block generation (assumed to be 30 days based on that article) = 90 days!

That is waaaay longer than was described above, yet seems to be what I'm experiencing. Can anyone confirm if this is indeed the case?

[Nas]

I think since Veeam Vault is based on Azure, the block generation is 10 days.

So 30 days retention + 30 days immutability + 10 days block generation = 70 days.

My concern is despite capacity consumed for 70 days but the backup browser UI will only show 30 days up to 42 days (max number of restore points for synthetic full dependent)

[BusterRox]

You're not alone in this regard. You are correct, VDCV does apply a 10-day block gen.
While the UI only shows what is configured as retention, the immutable data is still in the Vault. There is a Veeam Powershell command that will make that data visible if needed.

To me, the real question is, if your intention is to have 30-days of retention in VDCV and all 30 are to be indelible, how does one achieve this with minimal overhead via a copy job? Should we set job retention to 16 days and repo immutability to 14? However, I'd like all 30 days to be visible in the UI. Would setting job retention to 30 and repo immutability to 1 provide 30-ish visible restore points that are indelible? Adding to that, it seems I've found conflicting info regarding copy job GFS points either being immutable for the duration of the GFS or only the repo immutability, which is it?

[Nas]

I have been told that GFS restore points will remains immutable for the duration of GFS, so I hold on to that

[BusterRox]

I'm under the impression that if using copy jobs to object storage applies immutability for GFS differently than if using a SOBR. I also understand that the way object storage immutability is calculated in v13 has changed. I'm still not 100% sure how to deliver exactly what the client desires in their VDCV using copy jobs, which is 30-days of immutable retention with GFS set to 1w/3m/3y all immutable (understanding block gen is on top of that) using the latest version of v12. Then how will upgrading to v13, when available, impact all the above?