SOBR - Interaction between immutable performance tier, capacity tier & GFS jobs

[dandav]

I have implemented a SOBR with a single performance tier immutable Linux repository which is working well, however I'm a little confused with how VBR will handle the move to capacity tier if immutability is enabled and someone turns on GFS for a job once I add some object storage.

As I understand it if a GFS job is stored on an immutable repository then the immutability of the related objects is set to either the GFS retention time or the repository immutability setting, whichever is longer. If that is longer than the operational restore period is Veeam still able to move the objects to the capacity tier or are they stuck on the performance tier until the immutability expires?

[Mildur]

They will be automatically copied to the capacity tier.
After the immutable retention is over, they will be deleted. GFS Restore Points on Linux hardened Repo are always immutable until the gfs retention settings of the backup job deletes them.

From the Guide:

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

If you use the capacity tier option, keep in mind that having immutable repositories as performance extents will affect the capacity tier behavior. You will not be able to move the immutable backup files, because they cannot be deleted from the performance extent; Veeam Backup & Replication will copy such backup files to the capacity tier. When the immutability period is over, Veeam Backup & Replication will be able to delete these files from the performance extent. For more information on copy and move policies, see Copying Backups to Capacity Tier and Moving Backups to Capacity Tier.

[Gostev]

For SOBR with the Move policy enabled, GFS backups on Performance Extents are only locked according to the hardened repository immutability setting (as opposed to the entire GFS retention time) to enable the Move policy to function correctly.

Think of hardened repository immutability setting as a minimum time period to cover all your recent (most valuable) backups with ransomware protection. It should be long enough for you to have enough time to actually detect the attack is happening, which is why we don't even allow to set it to less than 1 week.

While extended immutability according to the GFS retention policy must only be set on the "final" media where the GFS full backup will ultimately be stored for its entire lifetime.

[dandav]

Excellent, thanks Gostev, that answers my question! Now to add that capacity extent

[lowlander]

Hi Gostev,

regarding your remark :

While extended immutability according to the GFS retention policy must only be set on the "final" media where the GFS full backup will ultimately be stored for its entire lifetime.

Using a Windows server as a backup target for the performance tier. How can we set immutability for the GFS backups on the capacity tier ( e.g. the monthly and yearly backups ) ?

[Gostev]

Capacity Tier does not support setting immutability for specific backup types, it protects all backups for the specified number of days.

[lowlander]

Thank you Gostev,

just to be sure I understand this

when we configure immutability on the bucket for 4 days, we add 10 additional days to it regarding to block generation resulting in a lock for 14 days.

when we have a GFS schedule for 4 dailies, 3 weeklies and 12 monthlies, this results in 19 restore points over the year in the capacity tier.

Am I correct that the dailies and weeklies will always be locked / the monthlies become unlocked after 7 months ( or be locked for 7 months ) ?

[Gostev]

No, you're not correct. Generally speaking, no restore points older than 4 days are guaranteed to be protect in this case, which is according to your settings. Block generation optimization has nothing to deal with just protecting every restore point in its entirety for an extra 10 days, it does not work like that in principle. But let's please not start yet another conversation about how it works, as it is irrelevant to this topic