Immutability retention ends 30 days after the last restore point in the active backup chain.
Update: Corrected my statement above
Immutability retention ends 30 days after the last restore point in the active backup chain.
Update: Corrected my statement above
Thanks, I had assumed you meant 30 and cited 10 based on the article, not based off of what I have immutability set for. With that said, 30 days after the last restore point would have been in December, not October 10 months from now, right?
Not necessarily. Immutability is for the amount of days configured after the last RP in the ACTIVE chain. An active chain is defined as a Full and its corresponding Increments. This doesn't mean the same as full restore points configured.
Reading the retention scenarios, it looks like Veeam could be setting the immutable period for full backup’s to comply with the retention policy, but it looks like both my full and incremental backup files have the immutability flag set for October 2nd. It’s a possibility that I had the rentention period set for 1 year initially, but that still doesn’t make sense since the last restore point is 11/30/23 and Veeam is reporting the files immutable until 10/2/24.
https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository_immutability.html?zoom_highlight=Immutability&ver=120#retention
Also, is it safe to assume, since this article addresses VHR, that it applies also to object?
Not necessarily. Immutability is for the amount of days configured after the last RP in the ACTIVE chain. An active chain is defined as a Full and its corresponding Increments. This doesn't mean the same as full restore points configured.
Ah, yes, thanks for pointing that out. That makes more sense.
So, for ex, if you have 30 RPs configured and do weekly synthetic fulls, then the active chain would be the current week's full & it's Increments. Make sense?
I'm went through storage issues on a brand new array right now because I also miscalculated this same thing 
Thanks Geoff, this is a good point, but I don’t think it applies here. We were initially using pay-go but I had support convert my account from 90 days to 30 days at the beginning, and we have since converted to RCS...although, I need to go back and look but the date looks suspect to approximately when we converted to RCS. Still, even 90 days immutability wouldn’t push me out to October.
So, for ex, if you have 30 RPs configured and do weekly synthetic fulls, then the active chain would be the current week's full & it's Increments. Make sense?
Yep, that part totally makes sense.
Thanks Geoff, this is a good point, but I don’t think it applies here. We were initially using pay-go but I had support convert my account from 90 days to 30 days at the beginning, and we have since converted to RCS...although, I need to go back and look but the date looks suspect to approximately when we converted to RCS. Still, even 90 days immutability wouldn’t push me out to October.
good point. I know some people here had some issues and the support folks at Wasabi were very responsive… and yeah October 
I keep thinking it is 2023 fall still
Reading the retention scenarios, it looks like Veeam could be setting the immutable period for full backup’s to comply with the retention policy, but it looks like both my full and incremental backup files have the immutability flag set for October 2nd. It’s a possibility that I had the rentention period set for 1 year initially, but that still doesn’t make sense since the last restore point is 11/30/23 and Veeam is reporting the files immutable until 10/2/24.
https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository_immutability.html?zoom_highlight=Immutability&ver=120#retention
Also, is it safe to assume, since this article addresses VHR, that it applies also to object?
To clarify a bit, I’m looking at this line regarding retention as I am using GFS retention.
- Veeam Backup & Replication compares the immutability period of the backup repository and the GFS backup file lifetime, and sets an immutability period for full backup files with GFS retention policy as equal to the longest of these periods. For example: the backup repository immutability period is 10 days; the GFS backup file lifetime is 3 years; the backup file will be immutable for 3 years; the increments from this full backup file will be immutable for 10 days from the moment of the last increment creation.
Thanks Geoff, this is a good point, but I don’t think it applies here. We were initially using pay-go but I had support convert my account from 90 days to 30 days at the beginning, and we have since converted to RCS...although, I need to go back and look but the date looks suspect to approximately when we converted to RCS. Still, even 90 days immutability wouldn’t push me out to October.
Right….so….I checked my emails and my confirmation email from Wasabi about converting to RCS was received on 10/2/2023, so I wonder if that could have caused some sort of issue where it set those files to be immutable to 10/2/2024 at that point? Seems like a strange coincidence….
Interesting indeed. Worth verifying I think.
I have sent an email to Wasabi support and will report back what we find. This might be troublesome if data can’t be deleted across all of our buckets for a year for those buckets that have less retention.
@dloseke there’s a great post by @rhys.hammond/@rhyshammond about this Understanding Immutability Periods for GFS Backups | rhyshammond.com
To confirm, do you have a GFS backup in Wasabi that is set for a year immutable? Veeam won’t report every date of every object, so as you’ve said a group of backups you want to delete it’s just giving you the furthest out I believe. Use an object browser to see if there’s any granularity in the acceptable deletion dates of the objects whilst you’re waiting for Wasabi to get back to you
To confirm, do you have a GFS backup in Wasabi that is set for a year immutable? Veeam won’t report every date of every object, so as you’ve said a group of backups you want to delete it’s just giving you the furthest out I believe. Use an object browser to see if there’s any granularity in the acceptable deletion dates of the objects whilst you’re waiting for Wasabi to get back to you
GFS is actually set to keep yearly for 3 years. So again, not making sense to me.
oh boy, some object investigation is needed then!
I have sent an email to Wasabi support and will report back what we find. This might be troublesome if data can’t be deleted across all of our buckets for a year for those buckets that have less retention.
Yes...keep us posted!
Hey Derek...did you hear back from Wasabi? Curious what they said.
Still investigating. I just pulled away to other issues and am just getting a chance to circle back around on this.
Ah ok. Was wondering about this the other day. Thanks for the update Derek.
