Backup Traffic Routing Wasabi to Azure

[mbroaders]

Can i get confirmation on how traffic routes to Azure when restoring from Wasabi Object Storage when :

a) there is no Azure Proxy
b) there is an Azure Proxy


Thanks!

[mbroaders]

I should of mentioned that the assumption is that there is a S2S VPN or ExpressRoute in place.

[mbroaders]

anyone able to assist?

[Gostev]

Chances are quite low during the weekend followed by a public holiday today in most of Europe

Since we don't support backup directly to Wasabi yet, restores are likewise will normally be served from an on-prem backup repository aka SOBR Performance Tier. Unless of course your production site is lost, but in this case you will start from deploying a new backup server in Azure, and all data will then go through this new backup server since it will carry all roles (except Azure proxy).

In case you're talking about the new 11a feature that allows to force restore process to use object storage in normal circumstances, then the data path should be as follows:
a) Object storage (Wasabi) > Object storage repository gateway server (running source and target data mover) > Restored VM disks on Azure page blob storage
b) Object storage (Wasabi) > Object storage repository gateway server (running source data mover) > Azure proxy appliance (running target data mover) > Restored VM disks on Azure page blob storage (mounted to proxy)

[mbroaders]

Thanks for the response Gostev much appreciated

The specific scenario i had in mind was with an on premise SOBR that has Wasabi Object Storage as the capacity tier. Veeam backs up on premise VMs and Azure based VMs. The Azure VMs are copied to on prem and go off to Wasabi (to take advantage of immutability). Am i correct in saying that traffic will flow via the object storage gateway server in and out? Is it possible to define a different route for restore traffic so, for example, restoring to Azure can : Object Storage (Wasabi) -> Veeam Azure Proxy -> Restored VM Disks on Azure Page Blob Storage ?

Hopefully i make sense!

[Gostev]

Why would restore be performed from Wasabi in the first place? As I already explained above, normally it will be from on-prem repo, which is a good thing because those are usually much faster.

Otherwise yes, object storage gateway server is involved in any scenario, as per my previous post. No way to bypass it, because that's where the data mover that interacts with object storage over S3 protocol runs.

[mbroaders]

Thanks Gostev. It's an edge case i guess but the thinking is that may be advantageous to utilize cloud to cloud bandwidth rather than the bandwidth from on premise to azure. An example that comes to mind may be if several servers needed to be restored then it may allow for optimization by allowing some restore traffic to utilize one route and other restore traffic via the other. Thanks for clearing up the current routing though. Will be very interested in how a direct restore from wasabi would look in the future if it becomes a feature.

[Gostev]

Actually, it's possible already with V11a to restore directly from Wasabi... you can tell Veeam to use backups in sitting Capacity Tier for restore (despite having backups on Performance Tier online and available).