VAW or VBA for 1 VM in Azure to Blob Storage

Direct to Object with VAW works great as I use it with Wasabi and will start testing with AWS now.  Might get to Azure at some point.  😂

I haven’t done direct to object (to Wasabi) yet with VAW, but I have done it with VBR for copy jobs.  Works great.  I do have a proposal that was signed though for VAW direct to Wasabi and managed by our service provider console, so I’m excited to set that up for the first time.

I mainly do direct to Object from VBR in my lab as I have many Wasabi repos set up.

😆 shall try not to disappoint!

I don’t believe that VSPC can work with “Cloud Machines” which is VBR’s way of deploying Veeam agents to AWS & Azure, I’ve not found anything in the documentation to suggest this is possible, but would love to be shown I’m wrong on that assumption!

Your main constraint with Veeam Agent is the recovery media. Azure doesn’t have the option of console access, and especially not that of IPMI/out of band management that could mount the ISO. Instead Veeam has to recover & convert the disk(s) and VM configuration. So if the VM goes bang, you can’t do a bare metal recovery.

You’ll have the following pros/cons with agent vs VBfMA:

Agent Pro: No need for additional worker VMs within Azure that contribute to costs

Agent Con: Lack of additional worker VMs means that backups are processed “in-guest”, consuming guest VM CPU & RAM.

VBfMA Pro: As you need some element of orchestration layer, VBfMA will help with other Azure services that might be consumed such as Azure SQL and Azure Files.

Neutral: Veeam Agent needs a VBR instance for Cloud Machine Backup and VBfMA needs to run as an appliance, running either of these in Azure results in a cost.

VBfMA Pro: Uses the service bus for communication to guest VMs for application aware processing, meaning no messing about with endless ports between Azure services. You can even run VBfMA in another Azure tenant (which you really should, just like you should run VBR in a bastion/management domain vs production domain)

VBfMA Pro: You can trigger snapshots within Azure for short term retention, allowing for better RPOs.

Just some thoughts that might help steer the decision making process. Have tried to give you the more useful bits but if this inspires any questions please spam us with them here 👍

Yeah, that’s was a wonder, but then I was thinking I’m not sure what would block that from working.  Else I need to setup a separate VBR instance and just managed via the console and not use the VCC server, but figured it would be great if I could.  I know what I’m going to try, and we’ll go from there.  If I had an Azure lab, I’d try it out, and I guess I could spin one up.  Either way, I can make it work I believe.

Thanks for all of these thoughts.  Lack of console access makes bare-metal recoveries difficult...I suppose it would look a lot like other agent-based backups.  I’d have to spin up a VM, install the agent, attach the agent to the repo, and then do a restore, rather than just a boot-from-ISO restore.  That there might cinch it for the VBfMA plugin/worker VM.  The VM itself as I have it sized looks to only cost about 36 bucks a month, so that might be fine in the grand scheme of things.  It feels to me like my first thought was the best thought, and the second though would work, but isn’t the best option, at least for recoveries.  But what’s the point of backing it up if you can’t recover properly.

Sounds like a good idea, and although there’s the initial outlay of cost, it then scales well 🙂

Also the worker appliances (not the base VBfMA appliance itself) can have a worker configuration of minimum worker VMs = 0 meaning it’ll only power one on when a backup job needs it 🙂

I’m currently looking into any way to auto shutdown the VBfMA appliance after all jobs have been completed for the day. But that’s early days…