Migrate from non-immutable repo to immutable repo

[scrat]

Sorry Mike! Another question, I guess it's the same with Object Storage in Veeam Backup for Azure, and with a SOBR in Veeam Backup & Replication, correct?
We can't migrate these repos to immutable backups until you have the migration process finalized.

Thanks!!

[Mildur]

Hi Scrat

I moved your question from Mikes topic.
The plans for VB365 are not relevant to VBR and Veeam Backup for Azure.

In VBR, you can use "Backup Move" to migrate backups from non-immutable to immutable storage. However, this cannot be done within a scale-out repository.
May I ask if your question is about Capacity Tier or immutable storage in the performance tier?
If it's about the performance tier, what type of repository are you referring to? For Hardened Repository, there is a workaround: https://www.veeam.com/kb4636

"Veeam Backup for Azure" doesn't allow you to move data to an immutable repository. You need to start with a new bucket and backup chains.

Best regards,
Fabian

[scrat]

Hi Mildur,
oh thanks! For VBR is about Capacity Tier, can we migrate the data from non-immutable to immutable storage?

For VBA we'll wait to the "migration tools" as VBO365.

Thanks,
Regards.

[Mildur]

Hello Scrat

For Capacity Tier, you need to download all data from the Capacity Tier to the Performance Tier, replace the buckets, and then let it offload again. The procedure is documented in our help center in subchapter "Migrating Data Between Different Cloud Providers":
-->Migrating Data Between Different Cloud Providers

Please note that downloading data from your Azure Blob capacity tier to the performance tier can lead to high costs due to API calls and egress traffic. It may be better to keep the current data on the existing blob container and start with a new immutable Azure storage container to offload only new backups.

Best regards,
Fabian

[veremin]

Additionally, there are currently restrictions that prohibit the configuration of Scale-Out Backup Repositories (SOBR) with extents from different cloud providers (e.g., one extent backed by Microsoft Azure Blob, and another by AWS S3). We understand that these restrictions (applicable to both Performance and Capacity Tiers) hinder user migration scenarios between different providers, and we plan to remove them in one of the next minor releases.

Thanks!

[Nas]

hi Vladimir,

does VBR allow to add new immutable Azure blob to the existing SOBR which consisted of local disk (performance tier) and non-immutable Azure blob (capacity tier)?

the plan is to seal non-immutable Azure blob and let the existing backups expire themselves and set the backup job to send new backup to new immutable Azure blob from performance tier.

[oleg.feoktistov]

Hi @Nas,

the plan is to seal non-immutable Azure blob and let the existing backups expire themselves and set the backup job to send new backup to new immutable Azure blob from performance tier.

Currently you cannot have both mutable and immutable extents even if one of them is sealed, but we plan to support this workflow in vNext.

Best regards,
Oleg