Immutability changes in 12.1

[pr_osit]

Hi there,

I noticed a change I haven't seen advertised between 12.0 and 12.1, I'm trying to clarify if this is just a change in wording, or a change in how the feature works. To test this myself would take a bit of time so would be good if I could get some clarification on this please.

In v12, this is the wording. We have tested this and confirmed that monthly GFS images have 12 months of immutability applied etc.


In v12.1 the wording has changed again, back to how it was in v11, it no longer mentions that GFS images are immutable for the duration of their retention policy. Does this mean that the immutability period is just the 30 days as defined here, or does the GFS retention immutability still apply, it's just no longer mentioned specifically?


What we want is just 30 days immutability, with no additional GFS retention immutability applied, so if that's how it's working in 12.1 would be good to know, thanks.

[Dima P.]

Hello Pat,

Looks like the text label was modified. No changed to the immutability logic were made i.e. it's still applied to the GFS restore points for entire duration of the GFS retention. Thank you!

[Gostev]

@pr_osit what wizard are you looking at? There are cases where GFS backups are NOT made immutable for the duration of their retention policy, for example in Capacity Tier.

[tina.cornelison]

What would be an example of GFS backups that are not made immutable?

[Gostev]

What I just mentioned: any GFS backup on SOBR Capacity Tier will not be made immutable for the duration of their retention policy but only according to the Capacity Tier immutability settings. However, on SOBR Archive Tier they will be made immutable for the duration of their retention policy.

[srlarsen]

We are trying to make sure we have an immutable copy of our GFS backups. We use SOBRs and have the "Copy backups to object storage as soon as they are created". If we do NOT check the "Move backups to object storage as they age out of the operational restore window", will our GFS backups remain in the Performance Tier and therefore stay immutable?

[Gostev]

What backup repository do you use for Performance Tier?

[tina.cornelison]

Our SOBR writes to AWS fist and then Google. We're getting ready to write to Wasabi first and then to Google.

[Gostev]

Both AWS and Wasabi support immutability, and since you're not using the Move policy, your GFS backups on Performance Tier will be immutable according to their retention policy > Immutability for Performance Tier

[pr_osit]

Hello Pat,

Looks like the text label was modified. No changed to the immutability logic were made i.e. it's still applied to the GFS restore points for entire duration of the GFS retention. Thank you!

Thanks for clarifying.

what wizard are you looking at? There are cases where GFS backups are NOT made immutable for the duration of their retention policy, for example in Capacity Tier.

Thanks Gostev, this is the wizard for adding Wasabi storage/object storage (no SOBR).
I'm looking for a way to store an offsite copy in Wasabi with only 30 days immutability, and no extra GFS immutability required.

[pr_osit]

It would be nice if there was an option to enable/disable the additional GFS retention immutability so that it's optional, is that something that might be permitted in future updates? I think a lot of people might find the granularity valuable.

[Gostev]

Yes, it's planned.

[jazzoberoi]

Hi Gostev,

In my humble personal opinion having Immutability / health check options in different places (repo / sobr / job) and different behaviours of where things are configured is getting confusing as the feature set of veeam grows over time.

Would love to see these consolidated in their own dedicated section perhaps? Could avoid confusion regarding what settings take precedence over what (repo or job) etc..

[Gostev]

Most complexities were due to using restore point based retention. As we deprecate the former in favor of time-based retention, things will get very simple as backups will be just made immutable according to their retention policy + we would have a single non-default override for those users who want them to be immutable for less e.g. only a few days.

[AlexHeylin]

If GFS backups are made immutable for their entire retention period, then the old text label was much better. If they're not then the new one is better.
Please can the text label match the functionality.

[Gostev]

I'm guessing it's a shared UI control and "it depends" thus the lowest common denominator... @Egor Yakovlev will know for sure.

[Egor Yakovlev]

Looks just like a bad text edit to me.
Investigating the roots of it.

[Egor Yakovlev]

Update.
The text edit was intentional, applies to object storage immutability cases only, and the idea behind it was exactly a spot-on case mentioned by Gostev in his first reply.
Nowadays object storage could be used as any tier of SOBR(Capacity\Performance\Archive) and GFS immutability applied differently in those. When adding object storage in the first place, we don't know the SOBR tier it will be used in yet, thus mentioning that GFS points will be immutable for the entire duration of their retention policy could be misleading.

[pr_osit]

Thank you for the updates, clarifies the confusion for me.

[jazzoberoi]

Hi Egor,
Thanks for clarification,
Can we please get a cheat sheet & best practices on where / how to set immutability for various scenarios.
- Job targeting SOBR (performance/ capacity / Archive)
- Job targeting Linux hardened repo
- Backup copy job targeting Wasabi S3

For example, we’d like to primary backup to Linux Hardened Repo (Immutability for 1yr) and Secondary backup to Wasabi S3 (Immutability for 7yr), how do we go about it?

SOBR or Backup + Backup Copy Job? Assuming we wish to go with GFS style restore points (7x daily, 4x weekly, 12x Monthly and 1x or 7x yearly)

[benthomas]

I replicated this table I saw at a local VeeamOn event for documenting what immutability is applied when

[benthomas]

Further information is actually available on Rhys' blog
https://rhyshammond.com/understanding-i ... s-backups/

[matt_778]

I have an issue with this setting too with Veeam12 and Backup Copy (non-SOBR) to Wasabi

I experienced a Veeam bug which wrote way too much data to Wasabi, about 90TB I think and was causing $$ (Case 07021504) I was then unable to delete all the Wasabi copies due to immutability.
Because of this thread, I now know that immutability works on GFS as well as the days setting on the repo.

Veeam support however don't seem to know this (case 07054177), they tell me its a Wasabi setting.

So, I would +1 vote for ability to change away from GFS immutability if desired.

[YouGotServered]

Hey all - just sharing my experience and workaround here:
I had a similar challenge. We wanted to migrate away from SOBR with on prem storage Performance tier + Wasabi Capacity tier (won't go into details here) to just a normal on-prem backup with backup copies to Wasabi (immutability enabled). We wanted GFS retention for several years but did NOT want immutability on the GFS restore points, because committing to keeping that data could end up being very expensive and forecasting the exact cost is difficult.

What we had to do was have 2 Wasabi buckets - one with immutability that we did about 30 days worth of backup copies to, and another without immutability where we sent a second backup copy with GFS retention.

So we ended up with x2 copies of our data in the cloud, but this is the only way we could avoid the risk of balooning data that we are unable to delete. Issue was raised here, and I'm looking forward to the behavior change mentioned above because it seems like a few people share the concern: object-storage-as-a-backup-target-f52/v ... 86009.html