Wasabi and Veeam 12 increases days Unexplained immutability

[Isra77]

Hello everyone.
I've been testing for weeks how Veeam 12 works with immutability and its block generation (10 days extra).
I have created a backup job directly to Wasabi with 1 day of immutability (+10 days) in total 11 days of immutability. This task has 30 days of retention, with full copy on Saturdays, attached image:





Everything seemed to work fine, the first copy was launched on October 11 and the immutability period was until October 22.
On October 21st (coinciding with the 10 days added by Veeam) a FULL copy was launched to break the blockchain and start a new one, everything was fine, that copy and the following ones had until November 1st as immutable. Attached image of VEEAM ONE of how everything was:




Now, on October 28, I have checked again in Veeam ONE how the job was going, as the result is that all the points (including those that had immutability date on October 22) have passed to have November 1 as immutability date, I do not find any sense to this when everything was working.




Can anyone help me? It is very important to know how it works because in my company we have many customers wanting to use immutability, but we do not trust that the cost in Wasabi is more a problem than a peace of mind.
Thank you very much and I hope you can help me!

[pirx]

I can't explain this, but I've seen this since beginning of using immutability years ago. It rarely matches immutable days + block generation. We have seen more than 20-50 days more over the years. I never found out why. Support recommended to change immutability to just 14 days. We had immutability set to 70 days (10 weeks) and had lots of backups with >130 days. Immutability was prolonged over and over, week for week. Usually one does not notice this, but we had backups that had to be deleted manually and that's when you start noticing it.

[Gostev]

When we're talking about block generation functionality, the immutability period is actually not set on "restore points" shown above, but rather on individual objects. The idea is that most objects are likely to be reused in the following restore points. So instead of setting (prolonging by 1 day) the immutability period on each object every backup run, which takes a costly API call, immutability on objects is set for a longer period right away.

Moreover, actually it's not always "+10 days extra", but "up to 10 days" depending on how far are you from the last full restore point (ever reducing value until the next full backup). As such, some restore points should have their immutability just slightly above the required period (which of course is always defined by the last restore point in the incremental backup chain, due to its dependency on the entire previous chain). Note that we use 10 days instead of "logical" 7 days (the typical frequency of periodic full backups is weekly) for the cases when full backup is missed on its regular day for whatever reason, and the issue takes a few days to sort out.

[knopfler]

Dear @Isra77

How do you have that info of immutability in the veeam software? What steps are you following to generate it?