-
- Expert
- Posts: 119
- Liked: 11 times
- Joined: Nov 16, 2020 2:58 pm
- Full Name: David Dunworthy
- Contact:
immutability durations at each level
I have linux immutable performance tier, aws s3 capacity tier, and glacier archive tier configured.
Backup retention is 21 daily, 6 weekly, 12 monthly, 2 yearly.
My current immutability settings are 7 days performance tier, 4 days (plus 10 block generation is my understanding) = 14 days s3 aws capacity tier, and then we have glacier lifetime of the gfs point immutability enabled so it stays until retention is over.
Is this OK? Could I do higher immutability settings length without issues on either of the first two tiers or is this correct already? I just don't want a large gap or misconfiguration.
Backup retention is 21 daily, 6 weekly, 12 monthly, 2 yearly.
My current immutability settings are 7 days performance tier, 4 days (plus 10 block generation is my understanding) = 14 days s3 aws capacity tier, and then we have glacier lifetime of the gfs point immutability enabled so it stays until retention is over.
Is this OK? Could I do higher immutability settings length without issues on either of the first two tiers or is this correct already? I just don't want a large gap or misconfiguration.
-
- Product Manager
- Posts: 9848
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: immutability durations at each level
Hi David
Can you tell us more about how you configured the different tiers? Copy or Move policy? How long until restore points are archived in the archive tier?
For the performance tier, immutability depends on how you have configured the offload policy.
With disabled move policy: The short term retention Backup Chain is immutable for 7 days, GFS Restore Points are immutable for their entire retention time. Example: Your two yearlie‘s will be immutable for two years.
With enabled move policy: The short term retention Backup Chain is immutable for 7 days, GFS Restore Points will be immutable for the configured immutability value, 7 days in your case.
If you configure a higher immutability setting on the performance tier, you will need more storage in both cases.
For the capacity tier, you should configure a lower or similar immutability period as your Archive backup files older than N days setting in the SOBR settings for the Archive tier. I don‘t have any experience with archive tier, we don‘t use it. But if the objects of a restore point is immutable in the capacity tier, it can not be removed from the capacity tier after it was archived and not needed anymore by any other restore point.
Can you tell us more about how you configured the different tiers? Copy or Move policy? How long until restore points are archived in the archive tier?
For the performance tier, immutability depends on how you have configured the offload policy.
With disabled move policy: The short term retention Backup Chain is immutable for 7 days, GFS Restore Points are immutable for their entire retention time. Example: Your two yearlie‘s will be immutable for two years.
With enabled move policy: The short term retention Backup Chain is immutable for 7 days, GFS Restore Points will be immutable for the configured immutability value, 7 days in your case.
If you configure a higher immutability setting on the performance tier, you will need more storage in both cases.
For the capacity tier, you should configure a lower or similar immutability period as your Archive backup files older than N days setting in the SOBR settings for the Archive tier. I don‘t have any experience with archive tier, we don‘t use it. But if the objects of a restore point is immutable in the capacity tier, it can not be removed from the capacity tier after it was archived and not needed anymore by any other restore point.
Product Management Analyst @ Veeam Software
-
- Expert
- Posts: 119
- Liked: 11 times
- Joined: Nov 16, 2020 2:58 pm
- Full Name: David Dunworthy
- Contact:
Re: immutability durations at each level
I use both copy and move mode. Gfs kept longer than 3 months are archived to the archive tier.
So immutability is 7 performance 14 capacity and lifetime archive tier. Seems ok from what you said. Since the short term chain is the max on copy mode that's one week as synthetic full is on Saturdays.
So immutability is 7 performance 14 capacity and lifetime archive tier. Seems ok from what you said. Since the short term chain is the max on copy mode that's one week as synthetic full is on Saturdays.
-
- Product Manager
- Posts: 9848
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: immutability durations at each level
It is ok for the capacity tier.
You could configure a higher immutability period for capacity tier, if you want to protect this data until it will be offloaded to Archive tier. You have configured 4(+10), but restore points will stay for another 75-80 days unprotected on the capacity tier before they are protected again on the archive tier.
7 days on performance tier with weekly fulls can give you immutable backups of 7-14 days. Veeam sets the immutability period starting with the last increment of a backup chain. In your case. It is the last increment + 7 days.
You could configure a higher immutability period for capacity tier, if you want to protect this data until it will be offloaded to Archive tier. You have configured 4(+10), but restore points will stay for another 75-80 days unprotected on the capacity tier before they are protected again on the archive tier.
7 days on performance tier with weekly fulls can give you immutable backups of 7-14 days. Veeam sets the immutability period starting with the last increment of a backup chain. In your case. It is the last increment + 7 days.
Product Management Analyst @ Veeam Software
-
- Expert
- Posts: 119
- Liked: 11 times
- Joined: Nov 16, 2020 2:58 pm
- Full Name: David Dunworthy
- Contact:
Re: immutability durations at each level
Ok thank you, so I can increase the capacity tier immutability setting higher like say 30 days and that will not have any negative impact to performance/archive tiers? It will just cost more money to keep the data longer etc.
-
- Product Manager
- Posts: 9848
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: immutability durations at each level
If I understand your statement „GFS kept longer than 3 months are archived to the archive tier“ correctly, you have always the last 21 daily, 6 weekly and 3 monthly gfs full backups on the capacity tier. Only gfs restore points older than 90 days will be offloaded to the archive tier.
Extending the immutability on the capacity tier from at least 4 days to 21 days should not lead to higher storage costs. The data will be stored there either way.
And all of your daily restore points would be protected. Not only the last 4 days.
Extending the immutability on the capacity tier from at least 4 days to 21 days should not lead to higher storage costs. The data will be stored there either way.
And all of your daily restore points would be protected. Not only the last 4 days.
Product Management Analyst @ Veeam Software
-
- Expert
- Posts: 119
- Liked: 11 times
- Joined: Nov 16, 2020 2:58 pm
- Full Name: David Dunworthy
- Contact:
Re: immutability durations at each level
Thanks. So 21 days would still then add up to 10 for block generation too though right?
I'll try changing and see if any issues.
I'll try changing and see if any issues.
-
- Product Manager
- Posts: 9848
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: immutability durations at each level
Yes, 1 to 10 days. First Full will be 21 days + 10 days.
Incremental could be fewer days.
This is done, so that veeam doesn‘t have to adjust immutability each day an incremental is offloaded (reduce I/O operations and associated costs).
Without this block generation, veeam would need to adjust the immutability of each object from the active backup chain every day a new incremental is uploaded. And amazon wants money for this operations
With the Block Generation, immutability on the objects is already configured with enough days and veeam doesn‘t have to adjust it each day to have your desired length.
Incremental could be fewer days.
This is done, so that veeam doesn‘t have to adjust immutability each day an incremental is offloaded (reduce I/O operations and associated costs).
Without this block generation, veeam would need to adjust the immutability of each object from the active backup chain every day a new incremental is uploaded. And amazon wants money for this operations
With the Block Generation, immutability on the objects is already configured with enough days and veeam doesn‘t have to adjust it each day to have your desired length.
Product Management Analyst @ Veeam Software
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 78 guests