Proposed B&R setup review, specific questions on Linux VM storage.

[Entropy]

Hello. Thanks in advance for sharing your time and expertise.

We’re a small shop, with very little Linux experience (we have 1 Linux VM for an obscure product that requires it). We use HyperV, but we’re not experts and this much proposed storage is new to us. Looking to move from Veeam Community Edition on a very non-ideal setup (not hardened, using 2x NAS as repos, etc.) to a full deployment to backup our one production HyperV server, a couple of still physical servers, and some critical workstations. Windows domain shop. Rapidly growing storage needs.

Given the above, I am considering the following approach to implement Veeam, a slight alteration to “Veeam in a box”:
1) HyperV 2019 host (non-domain joined, locked down), booting from a hardware RAID 1 volume dedicated to the host and the 2 planned guest OSes. New Supermicro hardware (Xeon Ice Lake, X12 mobo).

2) Guest 1: Windows server 2019 runs B&R. OS VHDx is on the previously mentioned RAID 1 volume. Hardened, non-domain joined setup. RAID 5 SSD repo via Intel VROC (ReFS formatted volume in host and within the guest) dedicated to this VM, enough space and speed for a few weeks of backups and running SureBackup and spinning up the protected VMs in the event of a disaster.
a. Note: I could do traditional hardware RAID card and SATA or SAS SSDs, but the cost is about the same, so I figured why not use NVMe.

3) Guest 2: Ubuntu 20, hardened. OS VHDx is on the previously mentioned RAID 1 volume. Repo will be RAID 60 on 7200 RPM SAS3 disks via JBOD disk shelf/hardware RAID. About 130TB total space. Run copy jobs from the main SSD repo in Guest 1 (traversing the virtual switch, no physical switch to bottleneck). Looking to use the storage for a mix of immutable and “regular” backups until we get more comfortable with just making everything immutable.

4) This hardware (the SM server and SAS3 direct attached JBOD/disk shelf) will be in a different physical location from the production HyperV server and physical servers we’re backing up, connected to the production HyperV server via 10 GigE (LACP 2x10GigE).

First, any glaring problems with the above approach? Not as secure on paper as having the Linux repo be a dedicated physical box, but easier to manage given our lack of Linux experience and saves some $ on host hardware.

My main concern is I am not sure how to present the RAID60 disk shelf via the HyperV host to the Linux VM. Specifically:

1) Linux immutable requires XFS formatting. I would assume that formatting the underlying RAID 60 volume in the HyperV host would cause problems here (because Windows does not support XFS). E.g. Windows host format the RAID 60 volume as one big ReFS space, then makes a traditional VHDx on top and attach to LInux VM. VHDx limit is 64TB as well, so it would need to be more than one VHDx. Then within the Linux VM those VHDx volumes are formatted as XFS (and end up being separate repos). Guessing this would not work well with respect to fast clone support of XFS? My ignorance of virtualization details is showing here.

2) Or, do I “pass through” the RAID 60 “device” to the Linux VM? This is old school (powershell only in 2019, no GUI support), but my understanding is that it’s still officially supported in HyperV. This gets around the host format and max VHDx size issues, but I am not sure if it causes other issues/risks.

Thanks again for reading and considering.

[HannesK]

Hello,
and welcome to the forums.

It's good that everybody believes, that XFS is required for immutability But it's only required for fastcloning (similar to REFS). Having that said, XFS should be used, yes.

I would go with a raw device mapping. Map the RAID60 directly into the Linux VM and format it there with XFS. At least my Hyper-V 2019 allows in the UI to add a physical disk. I don't believe that PowerShell is needed.

Best regards,
Hannes

[Entropy]

Thank you for the reply Hannes.

Appreciate the correction on XFS not required for immutability!

Glad to hear this is viable. Looks like cost is about an extra $3.5k to go with a standalone Linux repo (which would be about 8% of this project).

If we decide to stick with the JBOD / VM approach we'll test out passing through as a raw device on some spare hardware first (with a USB or spare SATA disk in place of the RAID 60).

Thanks again.