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!