immutable SOBR w/ hardened repositories + capacity tier

[Thomas Giguet]

Hi,
I am currently considering building a SOBR with immutability enabled to meet a customer's off-site backup copy needs and maybe use for other cloud tenants as well. After going over the documentation several times I am still unsure about the expected behavior in some areas, regarding mixing short retention, GFS, immutability with capacity tier in move mode (as in "using Hardened Repository in Capacity Tier" and "Immutability for Capacity Tier" sections).

what is needed : 14 day "short" retention + 12 monthly GFS backups (as active full backups if possible rather than synthetic)
we would like to avoid avoid storing monthly backups on both tiers, except for the 14 day immutability period on the performance tier

what we plan:
performance tier : hardened Linux - 14 day immutability
capactity tier (move after 14 days) : on premise s3 compatible - 365 day immutability

This way I expect GFS full backups, once created, to be kept 14 days on the performance tier before being moved to the capacity tier where they shall remain for the deserved 1 year period -all while being safe from deletion.
Is this correct ?

Thanks

[Mildur]

Hi Thomas

Yes, the move policy will allow you to that. Please note, that with "move after 14 days", you will see restore points between 14-21 days on your performance tier. We can only move restore points after the chain gots inactive (after a new full was created).
Additionally, I recommend to enable both policies. Copy + Move. This will allow you to immediately copy each restore point to the capacity tier instead of waiting 1 week.

what we plan:
performance tier : hardened Linux - 14 day immutability
capacity tier (move after 14 days) : on premise s3 compatible - 365 day immutability

Your capacity tier will be configured with 365 days of immutability. Be aware that we will never be able to delete offloaded daily backups after 14 days short term retention. Those objects will be immutable for 365 days. You should configure your backup job to keep 365 days of restore points (short term retention) if you want to make them immutable for 365 days.

Please use our calculator to estimate the storage usage for object storage with immutability. Making it immutable for 1 year could mean a huge storage consumption. You can find more information about it in our help center.
Our calculator can help you to make an estimation: https://www.veeam.com/calculators/simple/vbr/machines

Additionally, as a service provider you can consider to enable the governance mode for your backup server. Governance allows you to delete entire buckets/objects before the immutability period is over. This has to be done by a user account with the bypass governance mode S3 permission directly on the storage side.
The key will only work for VBR deployments where you haven't used immutable object storage repositories yet: S3GovernanceImmutabilityMode (DWORD, 1)



Best,
Fabian

[Thomas Giguet]

Thank you Fabian.
To make it clear : when enabling both policies (copy + move), each new backup file will be copied to the capacity tier and will be removed from the performance tier once my matched retention/immutability period is reached ?

[Gostev]

Once backup is older than your Move policy days setting. If I'm not mistaken, when Capacity Tier Move policy is enabled, Performance Tier immutability is automatically reduced accordingly to enable Move policy to actually function as it should and remove offloaded backups from Performance Tier.

[Mildur]

Correct.
Backup files will be copied immediately and removed from performance tier after the <immutability period> + <operational window period> is over.

With the move policy enabled, GFS restore points will be immutable for the time period specified in the hardened repository settings.
When move policy is disabled, GFS restore points will be made immutable on the performance tier for their entire retention period.

On Capacity Tier, GFS restore points will be immutable only for the specified time period in the object storage repository settings.

Best,
Fabian