-
- Service Provider
- Posts: 233
- Liked: 19 times
- Joined: Mar 29, 2016 3:37 pm
- Full Name: Matt Sharpe
- Contact:
Veeam Immutability for GFS
How does immutability work/need to be configured to ensure GFS points are kept immutability. I assume if we have 12 monthly GFS archives enabled on a job. If the immutability period is set to 7 or 14 days. The GFS archives (or the majority of them) are vulnerable to be deleted via an insider attack ?
Would we need to configure an immutability period of 365 days to protect them?
Would we need to configure an immutability period of 365 days to protect them?
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Veeam Immutability for GFS
Hi Matt
GFS restore points do not follow the repository immutability in all cases.
Standalone Object Storage repositories: immutable for the entire GFS retention period*
Object Storage in Performance Tier without Capacity Tier: immutable for the entire GFS retention period*
Object Storage in Performance Tier with Move Policy disabled: immutable for the entire GFS retention period*
Object Storage in Performance Tier with Move Policy enabled: Repository immutability
On Capacity tier: Repository immutability
On Archive Tier: immutable for the entire GFS retention period*
*if longer than Repository immutability, Repository immutability period is minimum for all backup files.
Best,
Fabian
GFS restore points do not follow the repository immutability in all cases.
Standalone Object Storage repositories: immutable for the entire GFS retention period*
Object Storage in Performance Tier without Capacity Tier: immutable for the entire GFS retention period*
Object Storage in Performance Tier with Move Policy disabled: immutable for the entire GFS retention period*
Object Storage in Performance Tier with Move Policy enabled: Repository immutability
On Capacity tier: Repository immutability
On Archive Tier: immutable for the entire GFS retention period*
*if longer than Repository immutability, Repository immutability period is minimum for all backup files.
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 233
- Liked: 19 times
- Joined: Mar 29, 2016 3:37 pm
- Full Name: Matt Sharpe
- Contact:
Re: Veeam Immutability for GFS
Hi Fabian,
"Standalone Object Storage repositories: immutable for the entire GFS retention period*"
Is this regardless of the immutability value set on the repository, or dependent on my point of 365 days immutability?
"Standalone Object Storage repositories: immutable for the entire GFS retention period*"
Is this regardless of the immutability value set on the repository, or dependent on my point of 365 days immutability?
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Veeam Immutability for GFS
Yes.
You can set immutability to 14 days. Your daily backups are immutable for 14 days (+ ~10 days)
And your monthly GFS restore points will be immutable for 12 months, because you have configured your GFS retention to 12 months.
Best,
Fabian
You can set immutability to 14 days. Your daily backups are immutable for 14 days (+ ~10 days)
And your monthly GFS restore points will be immutable for 12 months, because you have configured your GFS retention to 12 months.
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 233
- Liked: 19 times
- Joined: Mar 29, 2016 3:37 pm
- Full Name: Matt Sharpe
- Contact:
Re: Veeam Immutability for GFS
Understood, so for the new v12 direct to object (no SOBR) GFS archives are immutable for the configured duration. Thanks
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
Hi everyone - is there a way to NOT apply immutability to the entire GFS retention period for direct to object storage? We are backing up locally and doing backup copies to offsite immutable storage now with V12 (we were using SOBR, but there are some reasons I won't go into as to why we moved off). I have several clients that want to keep data "forever" or for "X" years until they start to get hit with the storage bills, and then they want to go in and trim it down. I'm afraid if I set a 5 year retention policy to satisfy them (for example) and in 2 or 3 years, they want to trim the data down, and then I have to tell them we can't.
It feels like I'm locking myself into a very long-term commitment by having to make several years worth of backup data immutable.
Any advice here?
It feels like I'm locking myself into a very long-term commitment by having to make several years worth of backup data immutable.
Any advice here?
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
Just wanted to check in and see if anyone had any suggestions on circumventing GFS immutable retention for life of the retention scheme. Thank you!
-
- Enthusiast
- Posts: 37
- Liked: 1 time
- Joined: Apr 11, 2019 11:37 am
- Full Name: Dejan Ilic
- Contact:
Re: Veeam Immutability for GFS
Fabian, What is the immutabiliy on performance and archive tier for this combination?Mildur wrote: ↑Mar 23, 2023 3:14 pm Object Storage in Performance Tier without Capacity Tier: immutable for the entire GFS retention period*
On Archive Tier: immutable for the entire GFS retention period*
*if longer than Repository immutability, Repository immutability period is minimum for all backup files.
Best,
Fabian
Object Storage in Performance Tier without Capacity Tier but with Archive Tier
Would the GFS be immutable on both tiers for the whole GFS retention period or just in archive tier?
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Veeam Immutability for GFS
@YouGotServered
No. It is not possible. I understand your request and use case.
@dejan.ilic@liu.se
I expect the same behavior as for hardened repository immutability. GFS backups will be immutable accordingly to the configured immutably period and not their GFS retention. I'll need to check on that.
Best,
Fabian
No. It is not possible. I understand your request and use case.
@dejan.ilic@liu.se
I expect the same behavior as for hardened repository immutability. GFS backups will be immutable accordingly to the configured immutably period and not their GFS retention. I'll need to check on that.
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
Mildur - could we please log this as a feature request? I think it is important to be able to decide whether or not we want data immutable for long periods of time or not
-
- Enthusiast
- Posts: 56
- Liked: 6 times
- Joined: Jun 18, 2009 2:27 pm
- Full Name: Yves Smolders
- Contact:
Re: Veeam Immutability for GFS
Additional question for this.
If a repository immutability was set for 31 days, for example, and we change it to 90, will all existing written data be changed to 90 days immutability?
If a repository immutability was set for 31 days, for example, and we change it to 90, will all existing written data be changed to 90 days immutability?
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Veeam Immutability for GFS
@dejan.ilic@liu.se
Behavior is as I have expected. When using object storage in the performance tier and Archive Tier is configured in the SOBR, we will set immutability according to repository settings, not GFS ones.
@YouGotServered
Yes, I logged the request. But no promises yet if it will made it to the product. I need to discuss the request on our side with the responsible team.
Best,
Fabian
Behavior is as I have expected. When using object storage in the performance tier and Archive Tier is configured in the SOBR, we will set immutability according to repository settings, not GFS ones.
@YouGotServered
Yes, I logged the request. But no promises yet if it will made it to the product. I need to discuss the request on our side with the responsible team.
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
Thank you!
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Veeam Immutability for GFS
@TonioRoffo
Only new restore points will be stored the new immutability period. For shared objects between older and newer restore points immutability will be extended to the new value when a new backup was taken.
Best,
Fabian
Only new restore points will be stored the new immutability period. For shared objects between older and newer restore points immutability will be extended to the new value when a new backup was taken.
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
Hey guys, I just wanted to circle back to this. I had a thought and wanted to know if this would work.
If I add an object storage repository to VBR with 30 day immutability, then I create a SOBR with the only extent a "performance" extent with my new object storage repository, could I do backup copy jobs with GFS from my local repository to my new SOBR with object storage in the primary extent and have it honor the repository immutability settings of 30 days only? I noticed above that this was said:
If I add an object storage repository to VBR with 30 day immutability, then I create a SOBR with the only extent a "performance" extent with my new object storage repository, could I do backup copy jobs with GFS from my local repository to my new SOBR with object storage in the primary extent and have it honor the repository immutability settings of 30 days only? I noticed above that this was said:
So I would have to have Move policy enabled? Move to what exactly? "Archive tier"? So if I am not moving anything to archive tier, I would still be subject to immutability lock on the entire GFS retention?Object Storage in Performance Tier with Move Policy disabled: immutable for the entire GFS retention period*
Object Storage in Performance Tier with Move Policy enabled: Repository immutability
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
Anyone have any input here? Thanks.
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Veeam Immutability for GFS
I apologize for the late answer.
When you use object storage as performance tier extends in a SOBR, you can configure any object storage as the capacity tier. Archive Tier is still optional.
With the move policy enabled, immutability will be set accordingly to the object storage repository settings. GFS immutability will not be used. That was done on purpose, so we can move backups to capacity tier. Moving wouldn't work if GFS backups are still immutable.
You could add a second bucket of your object storage solution as the capacity tier and move older backups to the second bucket. On the second bucket, you can use the same immutability period for all backups (daily, GFS). Please consider the required API call and Egress billing depending on the used object storage solution.
You may also try to use the max operational restore window of 999 days. That won't move backups with lower retention than 2.7 years.
Best,
Fabian
When you use object storage as performance tier extends in a SOBR, you can configure any object storage as the capacity tier. Archive Tier is still optional.
With the move policy enabled, immutability will be set accordingly to the object storage repository settings. GFS immutability will not be used. That was done on purpose, so we can move backups to capacity tier. Moving wouldn't work if GFS backups are still immutable.
You could add a second bucket of your object storage solution as the capacity tier and move older backups to the second bucket. On the second bucket, you can use the same immutability period for all backups (daily, GFS). Please consider the required API call and Egress billing depending on the used object storage solution.
You may also try to use the max operational restore window of 999 days. That won't move backups with lower retention than 2.7 years.
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
Well guys, looks like something along the lines of what I was afraid of happened and I wanted to ask for advice.
We gave an immutable bucket to a client. They were wondering why their storage was massively bloated (15TB data footprint, 80TB in Wasabi). They accidentally enabled GFS retention on it for three years. Looks like that data is stuck there and they are paying for it for three years, right?
By design, we can't delete the data from Veeam and you can't delete Wasabi buckets with immutable data from the Wasabi console.
Looks like they need a brand new Wasabi tenant, migrate data, then completely delete their old Wasabi account - is that right?
By design, I imagine there is no way around this - any thoughts?
We gave an immutable bucket to a client. They were wondering why their storage was massively bloated (15TB data footprint, 80TB in Wasabi). They accidentally enabled GFS retention on it for three years. Looks like that data is stuck there and they are paying for it for three years, right?
By design, we can't delete the data from Veeam and you can't delete Wasabi buckets with immutable data from the Wasabi console.
Looks like they need a brand new Wasabi tenant, migrate data, then completely delete their old Wasabi account - is that right?
By design, I imagine there is no way around this - any thoughts?
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Veeam Immutability for GFS
Hello Cory
I would create a new Wasabi account, use VeeaMover to move the job and it's backups to the new account. Then you can close the old Wasabi account. Please check first with Wasabi if that's something they allow your customer todo.
Best,
Fabian
Correct.Looks like that data is stuck there and they are paying for it for three years, right?
May I ask, how was the bucket used? I assume direct copy to object storage.Looks like they need a brand new Wasabi tenant, migrate data, then completely delete their old Wasabi account - is that right?
I would create a new Wasabi account, use VeeaMover to move the job and it's backups to the new account. Then you can close the old Wasabi account. Please check first with Wasabi if that's something they allow your customer todo.
Immutable is immutable. You may ask Wasabi support if they can delete data with a root access (root can always destroy data).By design, I imagine there is no way around this - any thoughts?
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 233
- Liked: 19 times
- Joined: Mar 29, 2016 3:37 pm
- Full Name: Matt Sharpe
- Contact:
Re: Veeam Immutability for GFS
With immutability and GFS, do that mean if an example GFS configuration (to retain 12 monthly GFS archives), is changed due to a company policy change or compliance change to say 6 months.
Will the GFS points reduce down to 6 months on the next GFS policy application?
I.E are the GFS points still organically removed as required to meet the configured RPO, just can't be forcefully deleted?
Will the GFS points reduce down to 6 months on the next GFS policy application?
I.E are the GFS points still organically removed as required to meet the configured RPO, just can't be forcefully deleted?
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
@Mildur,
Thanks for the response.
This bucket was used as a target for a backup copy job (not SOBR). They still want immutability, just no GFS, so only 30-60 days worth of data. If I use VeeaMover to move to another immutable bucket, I assume VeeaMover will also carry over the GFS restore points and the immutable flag and then I'll have the same issue. Is it better to just start fresh (which is fine), or am I wrong in my understanding?
Note, the big issue here is that we have about a years' worth of Veeam MS365 backup data in another bucket in the same tenant. We would also have to move that - is there a good process for doing that since we'll now have to reconfigure our MS365 backups as well?
I am happy to check with Wasabi on root privileges, does anyone have any experience here?
Thanks for the response.
This bucket was used as a target for a backup copy job (not SOBR). They still want immutability, just no GFS, so only 30-60 days worth of data. If I use VeeaMover to move to another immutable bucket, I assume VeeaMover will also carry over the GFS restore points and the immutable flag and then I'll have the same issue. Is it better to just start fresh (which is fine), or am I wrong in my understanding?
Note, the big issue here is that we have about a years' worth of Veeam MS365 backup data in another bucket in the same tenant. We would also have to move that - is there a good process for doing that since we'll now have to reconfigure our MS365 backups as well?
I am happy to check with Wasabi on root privileges, does anyone have any experience here?
-
- Lurker
- Posts: 1
- Liked: never
- Joined: Sep 20, 2023 1:39 pm
- Full Name: Matt Dailey
- Contact:
Re: Veeam Immutability for GFS
Just want to make sure that I understand this correctly. If I have a Backup job Direct to Object with Immutability on the Repo set at 7 days, and I have the GFS options enabled for 4 Weekly Full backups, 6 Monthly full backups, and 2 yearly full backups, then the Immutability for these backups is set to 2 years for all of these? or do they each follow the rules above with Weeklys being immutable for 4 weeks, then deleted when the 5th is created? etc. Also, shouldn't the daily incrementals fall off after on the 8th day?
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: Veeam Immutability for GFS
I believe the immutability is set for the shorter time at first and then the bits that are selected for that GFS point get the immutability extended to the life of the GFS point, but I’m probably a little off, so getting someone from Veeam to chime in would be awesome.
-
- Chief Product Officer
- Posts: 31806
- Liked: 7300 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Veeam Immutability for GFS
Every restore point is protected for at least the time from the repository settings. GFS restore points are protected for longer, according to their actual retention policy (so some weeks/months/years depending on the particular restore point).
-
- Service Provider
- Posts: 233
- Liked: 19 times
- Joined: Mar 29, 2016 3:37 pm
- Full Name: Matt Sharpe
- Contact:
Re: Veeam Immutability for GFS
If you reduce the GFS period, does the immutability period change along with it? Or retain the original period?
-
- Chief Product Officer
- Posts: 31806
- Liked: 7300 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Veeam Immutability for GFS
Once set, immutability can never be reduced (as having this functionality would enable an attack vector). So retaining the original period is the only possibility.
-
- Service Provider
- Posts: 192
- Liked: 38 times
- Joined: Oct 28, 2019 7:10 pm
- Full Name: Rob Miller
- Contact:
Re: Veeam Immutability for GFS
I thought had immutability all figured out from this post. However, it seems I don't. A common on-prem config for us:
Windows repo as the Performance tier in a SOBR - no immutability here
Azure Blob storage repo as Capacity tier and set to 30 days immutability.
SOBR set to Copy immediately to Capacity tier. Move is checked for backups older than 90 days. Since move is checked, I assumed it would use repo immutability settings.
Job set to retain 7 days of backups, with 4 weeks and 3 months GFS.
Based on the above stated logic from Mildur, I assumed that backups in Capacity tier would be immutable for 30 days +- 10 days.
I was just told from a Lead support rep that since our Capacity tier was set to 30 days immutability, which is longer than the 7 day standard job retention, that will then cause all GFS points to be immutable for their entire period, adding yet another layer of complexity to calculating immutability. Is that correct? Does anyone else feel this is getting a bit out of hand? I feel this is becoming overly complex and Veeam could simplify a lot of this logic in code, giving users a simpler interface to determine how they want immutability to function.
Windows repo as the Performance tier in a SOBR - no immutability here
Azure Blob storage repo as Capacity tier and set to 30 days immutability.
SOBR set to Copy immediately to Capacity tier. Move is checked for backups older than 90 days. Since move is checked, I assumed it would use repo immutability settings.
Job set to retain 7 days of backups, with 4 weeks and 3 months GFS.
Based on the above stated logic from Mildur, I assumed that backups in Capacity tier would be immutable for 30 days +- 10 days.
I was just told from a Lead support rep that since our Capacity tier was set to 30 days immutability, which is longer than the 7 day standard job retention, that will then cause all GFS points to be immutable for their entire period, adding yet another layer of complexity to calculating immutability. Is that correct? Does anyone else feel this is getting a bit out of hand? I feel this is becoming overly complex and Veeam could simplify a lot of this logic in code, giving users a simpler interface to determine how they want immutability to function.
-
- Chief Product Officer
- Posts: 31806
- Liked: 7300 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Veeam Immutability for GFS
You're spot on. I discussed the same with the team in great details last month and we have a good plan how to simplify this in V13. A few things in the immutability engine appeared to be overengineered, they can and should be simplified for better customer experience.
-
- Service Provider
- Posts: 233
- Liked: 19 times
- Joined: Mar 29, 2016 3:37 pm
- Full Name: Matt Sharpe
- Contact:
Re: Veeam Immutability for GFS
I just go with the logic that all GFS points are immutable for the duration of the retention period. Advising customers to be VERY careful when configuring this RPO.
-
- Service Provider
- Posts: 192
- Liked: 38 times
- Joined: Oct 28, 2019 7:10 pm
- Full Name: Rob Miller
- Contact:
Re: Veeam Immutability for GFS
Thanks Gostev. Yes it's really a pain point for us and with many different SEs involved, I'm worried about someone without advanced understanding of the complexities here to accidentally make backups immutable for far longer than needed. It's a real issue IMO.
This brings yet another concern however. We have a client who wants to keep all backups for 15 years. We are about to deploy. We want immutability on recent backups (30 days or whatever) only. Our plan was to:
Windows repo as the Performance tier in a SOBR - no immutability here
Azure Blob storage repo as Capacity tier and set to 30 days immutability. (we will now change this to 7 days it seems)
Azure Blob Archive as Archive Tier with no immutability - just in case they change their mind later.
7 day retention with GFS set to 4 week, 12 month, 15 year
Move GFS backups to Archive Tier after 90 days
If we encountered the same deal here, and had job retention set to 7 days, with 30 day immutability in the Capacity tier, are you saying that would then override the Move to Archive and set the GFS backups in the Capacity tier to 15 years? I hope not. That's scary as hell.
This brings yet another concern however. We have a client who wants to keep all backups for 15 years. We are about to deploy. We want immutability on recent backups (30 days or whatever) only. Our plan was to:
Windows repo as the Performance tier in a SOBR - no immutability here
Azure Blob storage repo as Capacity tier and set to 30 days immutability. (we will now change this to 7 days it seems)
Azure Blob Archive as Archive Tier with no immutability - just in case they change their mind later.
7 day retention with GFS set to 4 week, 12 month, 15 year
Move GFS backups to Archive Tier after 90 days
If we encountered the same deal here, and had job retention set to 7 days, with 30 day immutability in the Capacity tier, are you saying that would then override the Move to Archive and set the GFS backups in the Capacity tier to 15 years? I hope not. That's scary as hell.
Who is online
Users browsing this forum: No registered users and 15 guests