Is there something else I should be looking at that provides option 1 or 2 at lesser cost/complexity?

Without more details as to what is driving decisions, I'd use KVM, Starwind, and Veeam agent based.

Why, even Starwind (Anton) prefers agentless & Veeam's main products are all agentless.

Not the place to discuss, we covered this well about why this is effectively a necessity in another thread over the weekend. No one should "prefer" anything, that makes no sense. It should be the "right tool for the right job". Agentless is awesome, when you have the right situation for it, which I almost never see. My main issue with it is that it is deployed incorrectly almost always based on the belief that it is magic. That Veeam is a company that started by pioneering agentless is really not relevant and would never influence the decision. Microsoft used to be the world's largest UNIX maker, does that imply that using Hyper-V means we should only do so with UNIX workloads? Of course not, it's an unrelated fact.

@scottalanmiller Maybe you should tell Veeam they're doing it all wrong since their biggest & best selling products are agentless & btw Veeam's next big release is also agentless.

You are putting words in both my mouth and Veeam's mouth. Veeam is a business built on agentless. You are basically saying that because a company makes profit on something, that makes it right for consumers. That makes zero sense. Veeam is a business, they make what makes money.

Second, Veeam ALSO makes a big deal of building out their agent based systems. So the association of Veeam and their recommendation being agentless is totally incorrect. They make and sell that, and it's the best in the business, no question. But they also make agent based. So, by your logic, you've now accused Veeam of telling themselves that they got it wrong by having both.

Given that Veeam agentless can't be used in all scenarios, this also puts the idea that only agentless is okay in general, or for them, into question. How can something that can't be used for loads of normal scenarios, and really critical ones, be the only possible answer?

First, nothing in IT is always the answer. There are some bad ideas that are never the answer, of course. But nothing is an always.

Some Veeam history... Veeam entered the backup market to make a niche product, not a "do everything for everyone" product. They saw an opportunity for a new kind of backup leveraging new technology available in part of the industry. They made, and continue to make, a great product that works in this space. They have since branched out into the far more broad general use case space as well, not wanting to be limited to that "one trick pony" scenario.

Taking this basic business starting point, and turning that into the implication that 1) Veeam defines what good backup processes and approaches are based on the fact that they make lots of money doing it and 2) taking one product that they make and assuming that making that one product implies that Veeam themselves believe that that is the best or only answer to all needs. None of that is a logical result from the business fact of how Veeam made their fortunes.

If you look at this another way and look at Veeam's big competition like Veritas, IBM, CA, and so forth, they all focus on agent based backup. By that logic, they must all believe agent is always best and you have to then claim that they are wrong to ever say agentless is acceptable at times.

The only reason I use agent backups is because diffs/incs cant be done on XS by Unitrends. I use it for exchange sql and large file server and one application server. If this was possible, like Veeam does for VMware(maybe hyperv now I dunno), I would never use agents.

How am I putting words in your mouth...this is what you said in a previous reply..."Agentless is awesome, when you have the right situation for it, which I almost never see."

By implying that I was then telling Veeam that they got something wrong. I never suggested anything of the sort. That Veeam's agentless option is great for situations where it is the right fit is not even slightly the same as saying that they got things wrong.

In fact, I think Veeam agrees with me that agents are needed that's why Veeam spent so much money adding agent support! They think it is important, too.

No amount of believing that agents are important or useful becomes anti-Veeam in any fashion.

Veeam's agent-based backup software is great on our physical servers that are not VM hosts... but not needed on the Hyper-V hosts, as their agentless backup on that covers all the needs and provides a lot of benefits over sticking their agent on all VMs.

I have been using Veeam for over 5 years in a VMware environment. I love it. Their more recent addition of the agents was first to address physical desktops/workstations, then they went with physical servers and systems deployed in cloud environments where you didn't have access to the hypervisor or a supported hypervisor.

I used the agent for Windows server for an RDGateway/RDS physical box that I later ended up "P2Ving". I am now using the workstation agent for my current workstation.

I follow product announcements and issues pretty closely via their forum digest that is emailed pretty much every Sunday evening. The Veeam Agent for Linux most recently had a problem with the latest kernel updates in RHEL/CentOS, which caused the agent to crash. This issue was exclusive to the agent, whereas Veeam BR, didn't have any such issues.

On the other hand, VMware had issues with CBT on more than one occasion that was causing corruption in incremental/differential backups that Veeam was running. It wasn't Veeam's fault, because they were using the backup APIs that VMware provided and VMware had to fix the issue.

As others have said, you deploy the best solution for your use case. If you are backing up physical servers or cloud-deployed servers, Veeam agent is a good solution, provided you are aware of any limitations or issues with compatibility.