Veeam Immutability for GFS

[Gostev]

When Move to Archive is enabled, GFS are not made immutable for the duration of their retention policy until they actually land in archive.

[RobMiller86]

Ok thanks, so that shouldn't be a concern then, as long as an Archive Tier is enabled with Move, and Immutability is disabled on Archive Tier.

[YouGotServered]

Glad to hear changes in v13 are coming regarding this feature. Good to know I'm not the only one that was a little worried about this - I thought I was the crazy one for a minute!

[lsneed71]

Hi there.
I ask your forgiveness up front if this should be clearer to me, but I do want to verify something and would like to know if I'm heading down the wrong road. I appreciate your kind reply in advance
We have monthly backups set up with GFS, retention period over 60 months for each. Copying and moving backups currently to Capacity tier. Have not set up archive tier for the SOBR as of yet.
The storage account, unfortunately, was not set up with immutability enabled; we were no clear on whether we'd be able to place data in the container each month if immutability was enabled.

Is there any immutability anywhere in this scenario? In other words, if the first month's backup is set up with GFS to be retained for 60+ months, is that backup immutable on the capacity tier at all? Would it be immutable if we set up archive tier?

[Gostev]

Hello! If you didn't enable immutability in the settings of the object storage repository backing Capacity Tier, then your backups there are not immutable, simple as that. Same goes for Archive Tier. Thank you

[dtwiley]

Just reading this as we're having the same conversations with clients about the potential cost of long term backup retention, especially if immutability is used.

They, like us, feel that they want to protect the most recent backups with immutability to protect against ransomware, but protecting long term backups from ransomware is just not a concern. But the cost implications of not being able to trim the older backups when costs escalate is totally a concern. I think you need to decouple immutability from retention as they're two very different things in practice. Just because we say today we want to retain it for 5 years, doesn't mean we don't want the ability to delete it in 4 years. Obviously if we CHOOSE to make it immutable then this is our decision, but right now, sounds like many of us would choose not to but we can't.

Only way I can see around this is to have two copy jobs:
1. Daily job retaining say 31 days to a repo with immutability enabled for 31 days
2. GFS jobs running every week or month to a repo with immutability disabled

Problem with that is the additional storage costs and write operation costs.

Can I support this feature request formally?

[ericschott_OF]

@dtwiley

My understanding is you could do something like you describe, using SOBR, and SOBR move.

For the SOBR:
- create the performance tier with immutability. I would suggest on the bucket/repo set immutability 4-7 days.
- create your capacity tiers (and archive tiers if you need them) without immutability enabled on the bucket
- THIS WILL ENSURE THEY ARE NOT IMMUTABLE
- enable move or move+copy for the SOBR so that data is moved out of performance tier to capacity/archive as you see fit


- on your job, ensure you enable GFS weekly at least to 1 ie have it enabled, even if you think you do no want it.
- the reason for this is that it ensures the move could process sooner, as well as the actual removal of no longer needed backups (that already had retention done but are still in storage due to immutability settings)


So what should happen:
- performance tier will be operating effectively with immutability == retention, or until the move happens (whichever occurs first)
- the move cannot happen until the data is no longer in the active chain, and nothing depends on it. This is why we set weekly at least to 1 to ensure this happens sooner. Weekly > 1 is also fine if you want to keep more weekly's
- when the data moves to capacity or archive or waterfalls to both, it will not be immutable in these tiers
- if this is what you want, you have long term backups not immutable.

Another options you have is to enable immutability for only capacity tier. If you do this, set immutability on that bucket to 7 days
- no point in setting it higher as we set weekly >= 1 in the job
- the data in capacity tier with these settings will be immutable for 7 days.
- you can raise the bucket to make the data more than 7 days, but given you want to eventually flow into archive tier, I would not go too big on this repo setting vs. when you want the data to flow to archive tier and be deleted from capacity tier

[dtwiley]

Thanks, useful info. Would be nice for the GUI to let us control this though.