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
- Enthusiast
- Posts: 37
- Liked: 6 times
- Joined: Apr 11, 2018 7:47 am
- Contact:
-
TRE3
- Enthusiast
- Posts: 37
- Liked: 6 times
- Joined: Apr 11, 2018 7:47 am
- Contact:
Re: Move from mutable capacity tier to immutable capacity tier
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
- Product Manager
- Posts: 11303
- Liked: 3133 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Move from mutable capacity tier to immutable capacity tier
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
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
Product Management Analyst @ Veeam Software
-
TRE3
- Enthusiast
- Posts: 37
- Liked: 6 times
- Joined: Apr 11, 2018 7:47 am
- Contact:
Re: Move from mutable capacity tier to immutable capacity tier
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
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
Who is online
Users browsing this forum: No registered users and 9 guests