Since you can go directly to Object now from the VAW I would just do that instead of making things more complicated to set up and manage.  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.

Easier to manage, but I’m wondering about if I need to perform a full restore for some reason, how much harder will it be?

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

Therein lies the challenge possibly as you need to create the recovery media ISO to use for the restore.

Hello

Question: What do you plan on using for the orchestration of backups? Installing Veeam Agent directly? Hosting a VBR instance in Azure? Or VBfMA?

I almost tagged you in this because I knew you’d have the answers, or the questions to get me there.

Backups will be managed by the Service Provider Console.  I was planning on adding the Azure instance to the VCC server and using the VBA plugin to host a proxy appliance in Azure, but then as noted, I realized I could possibly just do the VAW on the VM directly.  Did not plan on a full VBR instance in Azure since it’s only a single VM.

My homelab is using a SOBR for the primary repo, archive tier is Wasabi.  Works great as well.  Work lab isn’t using object storage, but I plan on setting up a LHR on an older server with a bunch of local storage using the LHR ISO.  If I can ever find time to set it 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.

Yes, noted.  Bastion was another thing I was considering since the VM in question is also a Remote Desktop server that users will RDP into, so, obviously RDS on the internet - not great.  We’re augmenting that by requiring Duo MFA for all logins, but Bastion might be the better option here.  Again, all new to me.  But yes, the separate tenant for backups was something churning in the back of my mind.

What series VM are you looking at for RDS? also have you looked at Azure Virtual Desktop?

I scoped out a “A4 v2” in the North Central US region for the Sage 100/RDS server, and “B2s” for the Veeam appliance. 

I’ve not looked into Azure virtual desktop since there’s only about 5 users logging into the Sage 100 server.  That said, perhaps I should.  I have to license the server with 5-7 Windows Server 2022 RDS User CAL’s with Software Assurance in order to license RDS on the server.  That said, my thought was that by using it as a RDS server, the client doesn’t have to be upgraded on individual workstations or virtual desktops after the Sage 100 app has been upgraded on the server.  Again, only 5 users, but easier to not have to upgrade the virtual desktops as well, at least in my mind.

Hey, A series (and B series) would be a bad idea for RDS because of the low performance. Check out https://azure.microsoft.com/en-gb/pricing/details/virtual-machines/series/

You’ll likely be looking at a D or F series btw for the “recommended” experience. As for the VBfMA Appliance, yeah B series would be fine for the appliance with this workload size!

I’ll check that out...thanks for the suggestion!

Just as a followup for @Rick Vanover for the Community Recap, I’m going to stick with the Veeam Backup for Azure plugin over the agent simply because I will have better recoverability options.  Sure, the cost is a bit higher because I have a dedicated VM as a helper appliance, but I may also be turning off the app server after-hours to save on the cost of the VM running when it doesn’t need to be, and I can run backups while it’s off which will offset that worker VM cost.  Now, it’s obviously not as simple as using the Veeam agent, but there are added benefits!
 

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…

I like this idea.  At least the worker VM is relatively low expense, at least in my deployment.

@dloseke : perhaps an alternative way if you want to use Veeam agents on Azure VMs…

Backup to the VCC and setup at the service provider site a seperate VM with VBR (not used for VCC)  intended to restore full VMs to Azure again.

This VM has to have access to the VCC repositories so you can then import that backup and perform a direct restore to Azure when adding the Azure account of the customer in that VBR.

I hope you understand what I mean.