Immutability on Capacity Tier Move

[mbroaders]

Scenario is as below

Scale Out Repo 1
On Premise Veeam Hardened Repository
Primary Repository
30 days backups
Copy Mode to Wasabi

Scale Out Repo 2
On Premise Windows Repository
Backup Copies
12 Monthly GFS Points
5 Yearly GFS Points
Move Mode Enabled to move anything older than 1 month to Wasabi


Client wants immutability on all cloud points (Copied and Moved). What is the best way to configure this? I think i am confusing myself by reading the Block Generation support article.

[Mildur]

You can activate Object Lock on the Capacity Tier.
You can configure max 90 days in the GUI. Veeam will add 10 days to that value (Block Generation rule).
You can‘t activate Object Lock on existing buckets. You have to start fresh and configure them.

If you want more than this 100 days immutability on the s3 Object Storage, you need to use Powershell (999 days max value) to configure it. I don‘t recommend that.

https://helpcenter.veeam.com/archive/ba ... itory.html

Code: Select all

 Set-VBRAmazonS3CompatibleRepository -Repository <VBRAmazonS3CompatibleRepository> -ImmutabilityPeriod <int32>

—————-

For your SOBR 1 scenario, you will need weekly full or the object lock could be a problem if the full backup needs to be merged with the oldest increment.

[mbroaders]

We will have weekly Synthetic fulls on SOBR 1 so I think we are ok with this.

For SOBR 2 I am still confused. The plan is to move monthly and yearly backups up. The desired retention and by extent the desired immutability period for monthly backups is 12 months and 5 years for the yearly backups.

Is this achievable with the setup outlined above?

[Mildur]

I would try the config with 7-30 daily Restore Points and GFS with weekly, monthly and yearly fulls, and configure to move inactive chains after 30 days to capacity tier, then it could work with the only GFS Restore Points to Wasabi. I don‘t have my onpremise object storage to test it out for you yet.

But you cannot configure object lock for 5 years on a capacity tier. Max value in the shell is 999 days. This is around 3 years.

post391289.html#p391289

[mbroaders]

Thanks Mildur. That’s exactly what we are planning for the SOBR 2 points. 7 restore points, then Monthly and Yearly.
You have given me a bit to think about. I think even setting 1 year immutability on the SOBR 2 repository could be enough and that as you brought up is doable via powershell.

[mbroaders]

Just to come back to this, my initial confusion came from reading the following article about the hardened repo and assuming that the same settings took place when being sent to Object Storage. I take it that this isn't the case?

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

GFS backup files

If the backup repository is part of a scale-out backup repository with the capacity tier added, the immutability period for full backup files with GFS retention policy is set according to the backup repository setting.

Otherwise, the following periods will be compared: the immutability period set for the backup repository and the GFS backup file lifetime. The immutability period for full backup files with GFS retention policy will equal the longest of these periods.

[Gostev]

Yes, with SOBR it's a bit different, depending on the tier.

Capacity Tier provides short-term lock. The original goal for this functionality was the protection of recent backups against ransomware. Besides, long locks were perceived dangerous on expensive hot object storage classes (as you're going to be stuck with paying for storing your backups for as long as the lock was set, potentially years). Finally, for Amazon and Azure at least, backups are not supposed to stay on Capacity Tier for an extended time in any case, as there's also Archive Tier. And locking them for the entire retention duration on Capacity Tier would prevent offload to Archive Tier.

Archive Tier on the other hand functions just like hardened repository. We had no long-term data lock concerns here since it is 20 or more times cheaper than hot object storage.

[mbroaders]

Thanks Gostev appreciate the response. When you say that Archive Tier functions just like a hardened repository is this not only the case when using Amazon S3 Glacier? If Azure Archive Tier was used couldn't someone delete the backups using the Veeam Console before the retention period was up?
There seems to be a lot of caveats in and around immutability and the type of storage it is on.

[Gostev]

That is correct: Azure Archive Storage does not yet officially support Object Lock, the technology is currently in preview.