Questions on Migrating 1PB of Non-Immutable Azure Blob Data to Immutable Blob (SOBR Evacuate)

[dulgidulgi]

Hi everyone,

We are currently managing a large-scale backup environment with around 1PB of data stored in an Azure Blob Object Storage repository.
Our client recently requested to enable Immutability for this data. However, as you know, enabling immutability on an existing non-immutable Azure Blob repository is greyed out in Veeam.
To achieve this, we are planning to use a Scale-Out Backup Repository (SOBR). Our current idea is to add a new, immutability-enabled Azure Blob container to the Capacity Tier, and then perform an "Evacuate" on the old, non-immutable Azure Blob extent.
Since we have never managed a migration of this scale (1PB) before, we would highly appreciate some guidance. We have a few specific questions regarding this plan:

1. Veeam B&R Server Resource Usage during Evacuate:
We are currently using the Direct-to-Object storage method. When we trigger the "Evacuate" process, does the data flow directly through the Veeam B&R server's resources to pull data from the old Blob and push it to the new Immutable Blob?

2. Offloading with an Azure VM Gateway:
If we want to avoid putting a heavy processing load on our on-premises Veeam B&R server, would deploying a Windows/Linux VM inside Azure and assigning it as a Gateway Server for the Object Storage repository bypass the on-prem proxy resource bottleneck?

3. Storage Requirements for the Azure VM Gateway:
If we do deploy an Azure VM as a Gateway Server, does this VM need to have 1PB of local storage allocated to cache/process the data, or does it simply act as a data mover (pass-through) requiring minimal disk space?

As this is our first time handling such a massive data migration in Veeam, any advice, best practices, or real-world experiences from anyone who has done a similar migration would be greatly appreciated.

Thank you in advance!

[Mildur]

Hi jung ju yeong,

I don’t think we have benchmark numbers for repositories of that size, but please keep in mind that evacuating ~1 PB will likely take a long time (days).

1. With "direct connection mode", the Mount Server of your repositories will be used as the Gateway for offload jobs. If the mount server is not available, the backup server will take over. As an alternative, you can configure a dedicated Gateway Server for the source and target repository for the duration of the evacuation project.

2. Yes, deploying a dedicated Gateway Server in Azure makes sense. I wouldn’t be too worried about the load on the on‑premises Veeam B&R server; I’d be more concerned about the potentially very high API request, data retrieval and egress costs involved for 1 PB of objects.

3. No, it won’t require 1 PB of local storage.

Our current idea is to add a new, immutability-enabled Azure Blob container to the Capacity Tier, and then perform an "Evacuate" on the old, non-immutable Azure Blob extent.

Keep in mind the existing (old) capacity extent must be placed into “sealed” mode before you can add a new immutable extent to the same Capacity Tier. Also, plan for a maintenance window—offload jobs will not run while the migration/evacuation is running. For 1 PB, it will very likely take more than one day.

Instead of moving all backups, did you consider starting fresh with a new Capacity Tier and simply removing the old one once all backups stored there have aged out of retention?

Also; are the major part of this backups mostly historical/long‑term GFS data? If so, offloading older GFS restore points to the Archive Tier (immutability there as well) might be a better cost approach. Keeping ~1 PB in Archive Tier is typically much cheaper than keeping ~1 PB in Capacity Tier. You could use “Move to Archive Tier” first and then evacuate only the most recent backups on Capacity Tier to a new immutable Azure Blob capacity extent.

Best,
Fabian