Immutable capacity tier

[Evelynn1999]

Hi all,

Our organization has been using Veeam for 2 years now and currently using SOBR. The SOBR is made up a local repository and Azure BLOB for the capacity tier. When the SOBR was configured, Veeam did not support immutability for BLOB storage. However, now that Veeam 12 supports it, we are looking for the best way to bring in an immutable BLOB capacity tier into the existing SOBER and decommission the current non-immutable capacity tier. What would be the best way to accomplish this without losing the backups contained in the existing non-immutable capacity tier?

Thanks in advance! Any feedback is much appreciated!

-Evelynn

[Gostev]

Hello! Add a second, immutable extent to your Capacity Tier and then seal the original one. And later, once all backups on the first extent expire, you can simply remove it from SOBR. Thanks!

[veremin]

This will not necessarily work, as Capacity Tier has certain checks that prevent it from being configured in the mixed immutability state (some extents are immutable and some are not).

So, the proper way to migrate here will be to:

- remove previous non-immutable Capacity extents from the SOBR configuration
- add new immutable Capacity extents to it
- upon configuring the new Capacity Tier, you will be asked whether all backup chains or only the latest one should be copied
- select the latter option
- import backups from previously used Capacity extents
- manage their retention manually

Thanks!

[Gostev]

@veremin why do we apply above-mentioned check/restriction to unusable (sealed) extents? This does not make much sense.

[veremin]

Because sealed extents can be unsealed at any time and become usable again.

[Gostev]

Well, if we follow the same logic, then there's also no point to put criminals in prison because some clueless guard can let them out at any time?

Would not it make more sense to perform those "certain checks" you mentioned on an actual attempt to unseal an extent that is not compatible with active extents? Rather than blocking such configuration completely for everyone due to a mere possibility that someone may unseal it in future.

Just to remind, the one and only use case for the Seal functionality is to enable smooth migrations between different storage. So unsealing is not expected in general, however of course it should be blocked if it results in an invalid SOBR configuration.

[veremin]

Sure, sounds like a valid enhancement that we can discuss and introduce in the future. It's been noted. Thanks!

[rjv1971]

I've been thinking, researching on how to migrate our Veeam environment (backup-copy jobs) from writing to 'regular' Azure storage to 'immutable' azure storage. Then found and read this topic in the forums.

Is this all there is to it, as Gostev describes? Create an 'immutable' Azure storage account and container as per kb4416, add it to the scale-out repository and then seal the 'regular' one?

The next run of a backup copy job (they are all set to 'periodic copy (pruning)'): It will write the incremental copy to the performance tier, then the capacity tier part of the SOBR, which is set to 'Copy backups to object storage as soon as they are created' and 'Move backups to object storage as they age out of the operational window' (this is set to 1 day) will then automatically discover that the 'regular' extent is sealed and start writing the backup to the 'immutable' extent?

Will it create a new 'full' backup as it is now writing to a new Capacity Tier extent or is the new, immutable, backup an incremental backup and still dependent on the old 'regular' backup?

[veremin]

As mentioned above, the sealing approach will not work due to current product verifications prohibiting the configuration of SOBR in the mixed immutable state (only some of the extents are immutable). Thanks!