Questions about VM backups to immutable object storage

[vee789]

Hello team

My local Veeam contacts redirected me to this forum for my detailed questions about VM backups in combination with object storage and immutability.
Thank you very much for your time and answers.

We have the following environment and requirements:
- VMs running on iSCSI LUNs on NetApp ONTAP
- object storage as target with object lock in compliance mode (direct backup to onprem S3)
- for some repos we plan to use an SOBR with multiple performance tier buckets (no capacity/archive tier)
- immutability duration of around 60-90 days
- using the GFS backup schema
- Backup server with Windows, because of NetApp storage integration


Here are my questions:

1) What happens if we extend/increase the immutability period of the S3 repo after the first full backup?
For the HLR, we found the below statement that the immutability for the active chain is updated to reflect the new value.

If you increase the immutability period in repository settings, a new value will be applied for the active and next chains.
https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13

So for HLR the new value would be applied for the currently open chain, so for all restore points up to the last synthetic full, correct?
Here with object storage we have an incremental forever backup and only for the GFS backups, we have a synthetic full.

I would expect that new incremental backups are locked with the new period and that the pervious blocks from the initial full are not extended. But this leaves the problem, that those blocks can be deleted and the incremental backups are unusable as many blocks are missing.

What is the logic for VM backups to S3 (for increased immutability on the repo in regards to existing backups)?




2) I found some posts that on the HLR the immutability period of existing backup points can be extended.
E.g. the following post: https://community.veeam.com/blogs-and-p ... -v11a-1498
My local Veeam contacts said that this is not officially supported. But the blog post mentions publicly available PowerShell commands.
Is that method supported by Veeam or not for HLR?
Is such a method also available for VM backups directly to S3 and is it supported?



3) Regarding the GFS feature for VM backups directly to S3:
For some repos we plan to use an SOBR with multiple performance tier buckets (no capacity/archive tier)
I am unsure if I understood the immutability logic correctly when it comes to GFS.

Therefore, lets talk about the following example GFS config:
* 60 days of immutability on the repo, configured with the option "minimum immutability period only"
* 60 days of retention, there are daily VM backups so 60x daily backups
* GFS settings of 52x weekly, 24x monthly, 8x yearly




Here the docs pages that I found about GFS:

For the minimum immutability period only. In this case, the immutability period is the same as the immutability period of an object storage repository + Block Generation.
https://helpcenter.veeam.com/docs/vbr/u ... ier%20Only

For backups with GFS flags, VeeamZIP backups, and exported backup files, Veeam Backup & Replication applies the immutability period of the object storage repository. Retention of these backup files is not considered during the immutability period calculation.
https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13

My understanding is that with the option of "minimum immutability period only" the following restore points are immutable for 60 days:
* 60x daily backups
* 8x weekly backups of GFS
* 2x monthly backups of GFS

Is this true for both a SOBR with multiple S3 performance extents and for a "normal" S3 repo (meaning no SOBR) or how does it differ?



4) The "minimum immutability period only" is new with v13 and before with v12 the only option was "for the entire duration of their retention policy".
Is that correct?



Thank you for your time and support.

[david.domask]

Hi vee789,

Bit to ingest here, but I think I can help, let's take these one by one:

1. Extend immutability:

There are two options to consider in v13 for immutability as you can set it to the older minimum immutability duration, or for the entire retention period of the backup. The latter is heavily optimized to reduce total workload on the target S3, and generally recommended (fewer API calls, a major improvement in v13)

Increasing immutability will work like you have suspected, but all dependent objects will also have their immutability increased. However, I would advise consider using Export Backup for things like legal holds.

2. Set-VBRImmutabilityLockExpirationDate

Please see the cmdlet User Guide Page, it's a supported cmdlet, but it has some limitations. It will not help you here with Object Storage immutability, this cmdlet is for the Hardened Repository (local block linux repository)

3. Scale-out Backup Repository vs Direct Backup to Object Storage (SOBR vs DBOS)

The immutability will behave a bit differently as outlined on the User Guide pages. SOBR has an additional tiering concept (Capacity and Archive Tier) that allows for older backups to automatically tier to older storage, and some handling needs to be considered differently.

Ultimately, I would still advise with using the retention based immutability instead of repository minimum immutability.

4. Immutability methods

Yes, this was introduced newly in v13.

[vee789]

Hello David

Thanks for your time and effort.
I know, it is a long post, but as it is all in the same context I wanted to keep it together and not create multiple posts where I have to explain the context multiple times.
I am also happy with a direct call on Teams or Webex because this would be easier for the discussion.

-------

1) Extend immutability:

We need the "minimum immutability duration" because we don't want to have the GFS backups immutable as well. As mentioned, the customer wants to save some yearly backups and to have them immutable makes no sense. Especially since we don't know the space usage of the backups and want to be able to delete/reduace the yearly backups if needed to save space.

you can set it to the older minimum immutability duration

Are you saying that the "minimum immutability duration" as the "older mode" was there with v12 already?
This is contradicting to my understanding and to what you answered in part 4. There you are confirming, that the "minimum immutability" mode was introduced with v13.
=> Which statement is correct?

Increasing immutability will work like you have suspected, but all dependent objects will also have their immutability increased

So the immutability of existing objects (or blocks) from an initial full backup will also be extended if they are still used in a new backup with a higher immutability duration?
To be more concrete: If initially we had an immutability of 30 days and then we extend it to 60 days, then on the next job run, Veeam goes through all objects/blocks that are needed or related to the newest backup (with 60 days immutability) and will extend them?
I am asking because from what I have read, direct backup to S3 is incremental forever. And therefore, some objects/blocks from the initial full backup might need to be extended with every job run.
Is my understanding correct?



-------

3) Scale-out Backup Repository vs Direct Backup to Object Storage (SOBR vs DBOS)

SOBR has an additional tiering concept (Capacity and Archive Tier) that allows for older backups to automatically tier to older storage, and some handling needs to be considered differently.

I have read about this but I think this does not apply to my use case. I am not using the capacity or archive tier.
Because I am only using an SOBR with multiple performance extents. The reason is that I don't want to create one very large bucket that we don't run into issues with lots of objects. I was told if would be better to split it up into smaller buckets.

My understanding is that with the option of "minimum immutability period only", all restore points are locked for 70 days days after creation (60 days immutability plus 10 days block generation). But after 70 days, each restore point can be deleted by lowering the retention count in the GFS settings. This is true for both: 1) SOBR with only performance extents and 2) for DOBS.
* daily backups
* weekly backups of GFS
* monthly backups of GFS
* yearly backups of GFS

=> Can you confirm that?
I'd like to be sure and not get a bad surpise that I cannot delete yearly backups for 8 years.

Ultimately, I would still advise with using the retention based immutability instead of repository minimum immutability.

When you read my initial requirements, you can see that the customer only wants immutability for a subset of the retention. So that he is able to delete some restore points if he runs out of space on the backup storage.

Moreover, when I see the following sentence for SOBR, then this is another reason to not use your suggestion. As the setting "for the entire duration" would make the backups immutable for 8 years, if my understanding is correct (8x yearly backups are configured in GFS).

For the entire duration of their retention policy. In this case, the immutability period is the same as the GFS retention period + Block Generation.

https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13

Therefore, I don't understand why you are making this suggestion. Maybe you have overlooked my initial requirement?


.