[Feature Request] Appliance for Capacity Tier migrations

[micoolpaul]

Hi,

Apologies if this has already been asked, I couldn't find anything when searching however.

We now have the ability within VBR to migrate backups between extents in a SOBR at the capacity tier which is great, however we have the limitation of not being able to specify our own compute (at least that I've seen).

It would be great if we could specify a gateway server type resource that could handle the data migration for us between different extents. The way I currently understand this works (but haven't tested in anger yet) is that if I want to go from CapacityExtent1 to CapacityExtent2 and my VBR, Proxy & Repository resources are all on-prem is that I'll utilise either the VBR or the gateway server(s) to facilitate this. In cases where data migration is within the same cloud (Azure to Azure for example) this could be terribly inefficient by pulling data down to the datacentre only to upload again, but it wouldn't necessarily be appropriate to replace the gateway for the repositories just for the length of a migration between SOBRs, for reasons such as security reconfigurations or diverse routing.

Please steer me if I'm going about this the wrong way, but effectively as you've got a proxy appliance for the archiver already, I see scenarios where it would be useful to specify to use an appliance to facilitate the lift & shift between capacity tier extents.

Thanks!
Michael

[veremin]

Hi,

Could you please provide more details about the specific functionality you are referring to when mentioning the "ability to migrate backups between capacity extents"?

Thanks!

[micoolpaul]

Hi,

I mean when we configure a SOBR with multiple capacity tier extents for the purpose of migrating from one capacity tier extent to another. Primarily for migrations but I could see benefits for load balancing too when working at large scales (not that we’d really want to load balance object storage with metered APIs).

In my scenario here I’ve discovered a customer with an unsupported Azure storage account configuration that has over 700TB of Veeam backup blobs and the configuration issue in question can only be set at storage account creation, so now they’ve no choice but to migrate everything, but it makes no sense to pull the data down to the datacentre to upload again to the cloud

[veremin]

I'm still not entirely clear on what you mean by the migration scenario.

The primary concept behind the multi-extent capacity tier is to evenly distribute objects (such as per-VM backup chains) across multiple extents. As such, I'm curious about the specific instances where you believe a backup server would be used for migrating or moving this data (and where usage of helper appliance might come in handy).

Could you please provide more information or examples to help me better understand the context?

Thanks!

[Gostev]

As I understand, in Veeam terms he wants to evacuate a cloud extent to another cloud extent w/out incurring egress charges from pulling the data from cloud to on-prem first. Which will also take forever anyway.

What he's asking is possible by using cloud-native APIs though, no need for an appliance. I'm pretty sure we're already using those "in-cloud copy/move" APIs for some other feature, just can't remember which. But this is how I know they exist.

[micoolpaul]

Morning, Gostev is correct in interpreting my request. So, as things stand can I confirm that a cloud extent migration will always use either the VBR or gateway server to read from bucket A and write to bucket B? The documentation doesn’t really state “how” this feature works, just that it exists.

[veremin]

Understood, thanks, Michael, for the clarification.

Let me confirm a few things internally, and post back the outcome.

Thanks!

[veremin]

Currently, when evacuating backups from one capacity extent to another, the backups are being processed by the server specified as the gateway.

Indeed it seems logical to rely on the native commands provided by AWS or Microsoft Azure, as we already do in the case of exporting backups from the AWS S3 or Azure Blob capacity extent - in this scenario, data is copied via the native API, isolating traffic to the cloud, instead of passing through the gateway server.

I have tracked this request as a requirement for one of the future product versions.

Thanks for raising this!