HannesK wrote: ↑Feb 24, 2020 6:35 am
An agent installed directly on the Hyper-V host is a different machine not covered by the socket license. Please note that we do not recommend or support doing image-level backups of Hyper-V hosts themselves.
I'm confused why product management insists on retaining this limitation. How to protect the host was always a problem with Veeam since the beginning. When I asked about it at a Veeam demo, the sales rep told me "just have N+1 physical servers". (That's only a 4 or 5 figure addition to the budget.) Another argument is that it is so simple to set up a host, that you don't need a backup. But the fact is that there is more work involved in setting up a host than restoring it from a backup, which impacts RTO.
When free VAW came out, that was a decent work-around for the problem. But I believe free VAW stops working if an attempt was made to use a licensed VAW elsewhere. Customers using this approach won't dare to try out instance licensing. What's so special about hosts that they can't just be included when the sockets are already fully licensed for the VMs?
Hannes insists so simply because Hyper-V is not the workload we support with Veeam Agent for Windows today. This is for technical reasons, and it has nothing to do with the licensing. Thanks!
The use case for VAW on a Hyper-V host is protect the host OS. I think that is within the workloads VAW was designed for. I agree that attempting to back up VMs with VAW would not be a good idea.
Is the official stance of Veeam still as that sales rep advised - that N+1 physical systems is the best practice when using B&R to back up the VMs?
Hello,
actually I'm not sure what the N+1 question is about. N + X (X being the level of additional safety) is common for every kind of redundancy. Whether it is servers in a cluster or cars in a fleet.
I don't see, how the amount of virtualization hosts correlates to the backup software used. When hardware breaks, then some customers can live with performance degradation, while others cannot.
Just to make sure: your setup has a shared storage. So if one of the Hyper-V hosts fails, then the other three can just start the VMs. Correct?
At the sales demo I asked what the recommended process is to back up the host operating system. VAW didn't exist at the time. The sales rep's answer was to have N+1 servers available; meaning buy an extra physical server to sit there idle doing nothing waiting for one of the servers to break down. Then Veeam B&R could be used to restore the VMs to that idle server. That's a lot of money for a small shop to spend because a backup application doesn't support physical systems.
If Windows Update takes down a Hyper-V host, my preference would be to have a backup of the OS and just restore from that backup (which I can do with free VAW).
In the setup I manage, the storage is direct attached. It's not as simple as starting the VMs on another host. Even if the storage were shared, there would be licensing issues unless data center edition of Windows is being used on all of the hosts ($$$$).
I guess it's a different world for administrators that have the cash to invest in SANs and Windows Server Data Center. Although shared storage would keep me up at night. In a small environment, loss of the SAN would be loss of all of the VMs.
I see two options:
1) go with a not recommended way and restore the operating system with the agent (not the VMs)
2) re-install Hyper-V if something goes wrong and go with the VMs that are still available on the host (probably does not take much longer than a restore). By doing that, you do not lose any data.
the recommended way is, that the hypervisor is not relevant for the backup software (no matter which vendor. Nobody ever asked do back up ESXi ever for example). But I know, that in small Hyper-V environments, the situation is different (especially when people run applications in the management VM of Hyper-V)
Installing Windows Server fresh can be fairly quick. Downloading and installing all of the updates can take forever. I'm not sure if ESXi would need to be backed up, but Windows is a different animal.
On Server 2016+ all you need is the latest servicing stack update and cumulative update (and on 2019 the latest .NET CU). It's quite quick to patch a server fresh nowadays.
And I have personally installed the latest CU on Server 2019 on multiple occasions only to have it run through the download and install process of the same thing from Windows Update.
Overall, you're right that Server 2019 is not too bad. But I still think restoring from backup would be quicker and easier.