@Michael, I've fixed the link for you.
csydas wrote:But the point is, a Linux appliance isn't just some trivial thing. It's not a matter of "port the veeam agent over to *nix and call it a day", you lose tons of functionality.
Correct. I would put it this way - it would be trivial if Veeam was not so advanced and had all those "invisible" features that make a huge difference. For example, one type of issues we've ran into is our advanced NTFS processing features like BitLooker: they work perfectly on Windows proxies (using native NTFS driver), but crash left and right on Linux proxy with its NTFS driver. We wasted much time on this issue and gave up at some point.
One valid use case for Linux proxy that I am considering is the protection of clusters running purely Linux workloads - we do have such customers and this functionality would benefit them. There, we obviously would not have to worry about all that NTFS-related functionality. But then again, how do you prevent the rest of users from getting excited, deploying Linux proxies everywhere else and starting to open support cases complaining how this or that no longer works, or performs worse? That is always my challenge - how to ensure that some new feature does not impact customer satisfaction with our solution, considering that just about nobody reads the manual?
All in all, our choice of Windows platform for everything comes from one simple number - 90% of all VMs running on vSphere run Windows OS. It's not that we do not have any Linux expertise - if you were using Veeam back in its early versions, you know that all this product could do originally is process VMs running on "fat" ESX host with [effectively] an on-host Linux-based proxy. However, the introduction of ESXi and some our first innovations - as well as very limited development resources - have pushed us to focus on Windows proxies at the time.