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.
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?
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)
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.
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).
Therefore, I don't understand why you are making this suggestion. Maybe you have overlooked my initial requirement?
.
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.
Are you saying that the "minimum immutability duration" as the "older mode" was there with v12 already?you can set it to the older minimum immutability duration
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?
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?Increasing immutability will work like you have suspected, but all dependent objects will also have their immutability increased
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)
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.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.
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.
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.Ultimately, I would still advise with using the retention based immutability instead of repository minimum immutability.
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).
https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13For the entire duration of their retention policy. In this case, the immutability period is the same as the GFS retention period + Block Generation.
Therefore, I don't understand why you are making this suggestion. Maybe you have overlooked my initial requirement?
.
Statistics: Posted by vee789 — May 20, 2026 12:45 pm
