Move from mutable capacity tier to immutable capacity tier

[TRE3]

One of our VBR13 customers is using a SOBR consisting of a Performance Tier, an Azure mutable Capacity Tier, and an Archive Tier. They want to replace the mutable Capacity Tier with an immutable Capacity Tier. According to the instructions from https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13 , this requires creating a new immutable Capacity Tier and adding it to the SOBR. Then the old, mutable Object Storage must be sealed and evacuated.

Two questions regarding this:

1. Will all backups need to be downloaded to the local backup server and completely re-uploaded for this evacuation? If there is a way around, how can this be done as simply as possible?

2. What about the internal links between the old, mutable Capacity Tier and the Archive Tier? Will they remain intact, or does a completely new Archive Tier also need to be created? (The Archive Tier is currently also mutable but should remain that way.)

Thanks!

[TRE3]

I've read that Anton Gostev has unfortunately left Veeam. Is there someone else who can answer these questions, or should I create a support case for this?

[Mildur]

Hi Tre3,

It’s not only Anton who answers questions in these forums

Evacuation runs through the Gateway Server assigned to the object storage repository. The Gateway Server reads the blobs/objects from the source and writes them again with immutability enabled to the target repository. If your gateway server is on-premise, then it will be basically a "download". So you will get egress traffic and API calls during the migration.

The Archive Tier won’t be affected by a Capacity Tier evacuation — there’s no need to create a new Archive Tier.

Did the customer use the MOVE or COPY policy for his Capacity Tier?

Best regards,
Fabian

[TRE3]

Thanks for your feedback! The customer is using copy and move for his capacity tier.

How exactly should we proceed to prevent egress costs? Would we need to create a Veeam VM from the Azure Marketplace, read the Azure data into it, and then perform the evacuation? However, without a site-to-site VPN, we can't access the SOBR performance tier. Could we do it like this:

1. Create a new immutable capacity tier/repository and add it to the SOBR
2. Do NOT perform evacuate for the existing capacity tier and simply remove it from the SOBR
3. Upload the performance tier data to the new capacity tier
4. Delete the old capacity tier completely after 30 days

Would the archive tier linkage then be broken? Or would we need to create a new archive tier as well? And can we still access the old archive tier data?

Best regards,
Tom

[Mildur]

Hi TRE3,

Yes, you can deploy a VM in Azure and assign it to the object storage as a Gateway Server.
Evacuation happens automatically — you don’t need to download anything manually. The Gateway Server reads data from the source extent and writes objects to the target extent.

It may be possible to run the Gateway Server without a VPN by selecting the option "Run server on this side" in the Advanced Connection Settings. However, using a VPN is still recommended.

May I ask — would it also be acceptable for the customer to simply leave the old Capacity Tier extent until the data ages out?
That approach would save them the challenges, resources, and costs associated with migration.
How long is the current retention period in the Capacity Tier?

Best regards,
Fabian