VBR in Hyper-V VM - Storage Question

[dhayes16]

Hello. Sorry for what may seem basic questions. So we have a 2019 windows server dedicated at the moment for Veeam. There is a C: drive with SSD for the OS and a D: formatted ReFS with about 34TB of usable storage. Note that this is a DR site and we have another server at a main site with the same specs.

So others have mentioned we should install Veeam B&R into a VM and this makes sense. So it easy enough to spin up the VM (likely 2019) and install Veeam B&R 11. So we have the following questions.

#1) We want to point VBR running on the VM to the formatted ReFS D: drive running on the same Hyper-V Host. Should we point the repo to \\host\Veeam Repo? Or create Hyper-V virtual disk and mount that to the VM setup as fixed disk or dynamically allocated? I am just wondering what best practice is here?

#2) Should the WAN accelerator cache folder exist on the VM itself or point to a location on the host? Possibly like #1 above.? Just making sure we size the VM correctly.

#3) Replicas. I am curious to where people would point the Replicas and the associated VM's when VBR is loaded in a VM. I am assuming the replicas would point to the Hyper-V host with the role installed or in the VM iself with the Hyper-V role installed there.

I just want to understand the pros and cons of putting VBR into a VM and the best way to handle the repo storage access on the host as well as other related services.

Thanks again!
Dave

[HannesK]

Hello,
as you mentioned that the server is dedicated for Veeam, I would avoid Hyper-V for that machine completely. It just adds complexity. I would go with plain Windows + Veeam on that server. KISS

The question is, whether you really need two VBR servers (one for each site). With a classic active / passive site-concept I would put the VBR server in the DR site as you mentioned. The second (identical) server in the production site can be used as repository (for backups on the production site) and WAN accelerator.

#1) I don't like the idea at all, but if I was forced to do it, I would use the disk directly to avoid a useless layer that might created issues.

#2) in the VM

#3) VMs are replicated from Hyper-V to Hyper-V. The VBR server is out of scope here. https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Best regards,
Hannes

[dhayes16]

Thanks for the reply. I do agree with what you are saying about KISS. That was the original plan since the server is dedicated to Veeam and it is very well speced. But other people suggested this could be problematic running on the parent partition. Perhaps it was assumed this was a production hyperv host when it is really not.

The reason we would install hyperv is for the the need to recover vms and failover to this server in the event that the primary server failed hard.

Again thanks.

[HannesK]

But other people suggested this could be problematic running on the parent partition

agree with these people If you want to use the server as replication or restore destination, then VBR must be installed inside a VM, yes.

With "plain windows server" I mean that there is no Hyper-V. Installing VBR in the parent partition is unsupported by Veeam and also by Microsoft because applications must not run in the Hyper-V parent partition.

I always suggest designs where the backup server is really a standalone machine that can live without any dependencies. That makes it easier to secure and one cannot run in chicken-egg issues.

[dhayes16]

Thanks. Then we will go into the a vm. But I guess the question I would have is what is the best way to present the repo to the vm if the storage for that repo is on the hyperv host itself. There are many ways to do it but I am curious which would be best in this situation.. \\host\repo or virtual disk presented to the vm? (dedicated vm)? The latter seems better but then we need to define a very large fixed virtual disk.

Thanks.

[HannesK]

the Veeam best practice guide says what I stated earlier: use the disk directly ("not to use VMFS") https://bp.veeam.com/vbr/VBP/2_Design_S ... iderations

The reason is filesystem corruption. If you rate that risk as irrelevant, then it's irrelevant for you

[dhayes16]

Thanks for your input. Truly appreciate it.

I do have a followup on this especially in regard to your point about whether we really need 2 vbr servers.

1. If we do best practice and have the vbr server at the DR site handle replication is there any compelling reason to having the vbr server at the main site handle functions like local backups and backup copy jobs to the DR site repo? I know the DR site can handle all orchestration of backup jobs through proper proxy setup. However if we had another vbr server at the main site would it make recovery or "local" DR easier/faster? For instance if the primary hyperv production host goes down we would want to be able to spin up vms on the local BDR as soon as possible (not from the DR site). So would having a second VBR server loaded locally help facilitate this local DR functionality?

2. Also we plan to have replication going to the Dr site as indicated. But since we have the server resources on the local bdr (it is a twin of the Dr server) would there be a benefit to having "local" replication jobs to the local BDR to be able to bring up those vms quickly as opposed to relying on instant recovery per vm?

3. Is there benefit to having the vbr server exist at the main production site ONLY in a vm and then replicating that vm to the Dr site in case eif disaster? I am seeing references to that. We just want to do things as per best practice and support 100%.

Both BDRs will have the hyperv role installed with the vbrs running in vms.

Obviously having one vbr makes things more concise and everything would be in one place.

Thanks

[HannesK]

1. I would go with one VBR server if you expect a stable network connection.

2. Replication is possible if you have enough resources, yes. As mentioned earlier, I prefer separation of duties (meaning that hardware is dedicated to a backup product). I understand that this can be complicated for SMB customers.

3. I would put it in a VM at DR site and replicate to production (assuming that the disaster strikes at headquarter). The advantage would be separation of duties.