V13 Appliance Questions

[bigzell]

Hi,

In Veeam v13, can iSCSI or NFS storage be mounted directly to the backup appliance so that it can act as a repository server in small environments? Additionally, for features such as AD and SQL, is a Windows-based mount server still required, or can this be handled entirely without Windows — meaning the whole backup infrastructure could run on Linux only?

[HannesK]

Hello,

1. NFS repositories would work, yes. But I recommend avoiding them because NFS doesn't support reflink / fastclone or to use "active full" with NFS.
2. iSCSI: no, only internal storage is supported for the appliances. There is no iSCSI initiator option
3. Mount server: All "roles" can run on Linux. Some edge cases do not work (like REFS restore), but all common scenarios are covered. For the Explorers and Windows console, a Windows machine is still needed. That would be the AD & SQL part you asked for (I assume that would be about Explorers).

Best regards
Hannes

[Gostev]

3. The other way I like to say this is "if you don't use Windows in production environment, then you don't need it for your Veeam backup infrastructure". The problem before V13 was that Veeam required at least one Windows server to protect a Linux-only environment, which did not make much sense.

However, if you do protect Windows servers, then you do want to assign a Windows machine as a mount server to be able to mount the corresponding backups without worrying about edge cases and to do application-item recovery from backups of Microsoft enterprise apps with Veeam Explorers.

[bigzell]

If you are backing up application items in Windows-based environments, is it correct that a Windows-based mount server is still required?

In our case, we typically install the VBR console on a Windows VDI to connect to backup servers remotely. If application item recovery is initiated from this console, would the VDI automatically function as the mount server if none is explicitly defined in the VBR appliance GUI?

For smaller environments, is it considered a supported approach to use the VBR software appliance in combination with a single Windows server that serves both as the repository and the mount server?

[Gostev]

It is supported but I would never recommend Windows for a standalone repository. It's one thing when you have all-in-one install with everything on a Windows server. But if you do have a standalone server to spare for a repository, it has to be a hardened repository for immutability and, err, all the hardening.

[JaySt]

how about the vPower NFS service. Is this fully available on Linux as well now to do surebackup?
This is actually one my use cases where a windows repository would make sense imho (keeping vPowerNFS access to backup files locally on the repository).

[Gostev]

Yes, it is.

[bigzell]

Just to clarify, when using the VBR software appliance, is the recommended approach — even in smaller environments — to have a separate Linux-based repository server and a Windows-based mount server if backing up and restoring application items?

[HannesK]

Hello,
the separate server makes sense to meet the 3-2-1 rule, yes (except you use something else for additional copy).

I don't see a need for a separate Windows mount server for your scenario. But to use the Explorers, Windows is needed. That Windows machine could act as mount server if you have some special needs (REFS, Windows deduplication enabled...) but from your description I don't see a reason.

Best regards
Hannes

[Zweistein]

Hello,
2. iSCSI: no, only internal storage is supported for the appliances. There is no iSCSI initiator option

Best regards
Hannes

Please add the iSCSI initator from the Linux OS of the Appliance, so we can user the existing systems as local drives.

[Gostev]

This would significantly increase the attack surface of the appliance due the addition of iscsid daemon running under root and with network access. This goes goes against our promise of VSA being hardened against cyberattacks.

In general, we recommend separating management server and backup storage by deploying standalone hardened repositories on general-purpose server hardware.

[dmitri-va]

We currently use VBRv12 on windows servers with iSCSI initiators connecting to SAN so we can use direct SAN backups/restores.
Will Appliance ever support it?
If yes, will it ever support storage integration, namely with Dell PowerStore SANs?

Thanks.

[Gostev]

We do support direct SAN connectivity for backup proxies provisioned from Veeam Infrastructure Appliance ISO (you will see the corresponding deployment options directly in the installer) but not for Veeam Software Appliance itself. It's unlikely that the latter will support it for the previously mentioned reason.

Yes, for details see the Primary Storage Integrations section of the What's New document.

[dmitri-va]

ok, so no support for 3 in 1 then (mgmt, proxy, repository) on a single server.

btw, the above mentioned security concern should not apply, as we are talking about iscsi initiator, not iscsi target on the appliance in our scenario

[Gostev]

Full support for 3 in 1, the only limitation is no Direct SAN transport mode is available for VMware.

Security concerns do apply because iscsid running under root can be made to connect to an iSCSI target controlled by a malicious actor. As you know, iSCSI protocol was not exactly designed with security in mind.

[dmitri-va]

hmm, you have to break into this purposely built minimum OS secure appliance at which point you own it already, so saying that then a possibility of connecting to some malicious iscsi target made you decide to not support an iscsi initiator on it is a stretch, in my mind.
further following this logic, it's a risk then to run an iscsi initiator on the Infrastructure appliance as well, and even more so on a generic Windows server that we've been doing for years.....
btw, we'd gladly switch to NVMe/IP a long time ago if Veeam supported it.
Overall, as much as we've been excited to possibly switch away from windows based platform for Veeam, between these limitations and the push to VUL licenses will most likely be show stoppers for us.
I know its not the place for license discussions, but why on earth did you decide that stopping something as crucial as protecting workloads if you are over the VUL license limit (+ puny 20VM overhead) is worth it.... was true-up licensing model even considered.... makes so much more sense.

[Gostev]

Of course, you're more than welcome to remain on the Windows platform if that is beneficial for your environment. Veeam always stood out with its power of choice and VSA is just another choice we're bringing to make even more customers happier. And while many customers love the idea, we do realize it's not for everyone.

why on earth did you decide

We did not, R&D does not make licensing decisions. Just a small correction, technically speaking the overhead is "20 or 20%, whichever is greater".

[dmitri-va]

ah, I overlooked, so thank you for pointing this out.
the link I was provided by support: https://helpcenter.veeam.com/docs/backu ... ml?ver=120
stated: "Workloads that are exceeding the license limit beyond 20 instances (or 20% of the total instance count) are not processed." - so I read it as "20 VMs or less".
Only now that I scrolled and read further down in that article I saw an example where they stated: "you are allowed to use up to 20 instances or 20% of the total instance count (whichever number is greater) over the license limit"