Discussions related to using object storage as a backup target.
Gostev
Chief Product Officer
Posts: 31812
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Veeam Immutability for GFS

Post by 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
Service Provider
Posts: 192
Liked: 38 times
Joined: Oct 28, 2019 7:10 pm
Full Name: Rob Miller
Contact:

Re: Veeam Immutability for GFS

Post by 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
Service Provider
Posts: 176
Liked: 53 times
Joined: Mar 11, 2016 7:41 pm
Full Name: Cory Wallace
Contact:

Re: Veeam Immutability for GFS

Post by 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
Novice
Posts: 5
Liked: 1 time
Joined: Jun 29, 2022 2:48 pm
Full Name: LaTonya Sneed
Contact:

Re: Veeam Immutability for GFS

Post by 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
Chief Product Officer
Posts: 31812
Liked: 7302 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Veeam Immutability for GFS

Post by 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
Enthusiast
Posts: 91
Liked: 5 times
Joined: Aug 26, 2014 1:33 pm
Full Name: Dave Twilley
Contact:

Re: Veeam Immutability for GFS

Post by 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
Service Provider
Posts: 7
Liked: 6 times
Joined: Oct 06, 2023 4:46 pm
Full Name: Eric Schott
Contact:

Re: Veeam Immutability for GFS

Post by ericschott_OF » 1 person likes this post

@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
Enthusiast
Posts: 91
Liked: 5 times
Joined: Aug 26, 2014 1:33 pm
Full Name: Dave Twilley
Contact:

Re: Veeam Immutability for GFS

Post by dtwiley »

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

Who is online

Users browsing this forum: Semrush [Bot] and 23 guests