Feature Request - VBR

[dips]

Hello,
I'd just like to suggest a feature request when performing an install/upgrade of VBR.
Currently, when installing VBR, it automatically installs the Veeam Explorers for multiple products. This will also include explorers we do not utilise within our environment. Can this be changed so the required explorers can be selected?
At the moment, once the install has been completed, the Explorers have to be manually uninstalled.
Thanks!
Dips

[HannesK]

Hello,
what's the goal of removing explorers? Overall we removed as many options from the setup as possible to simplify the installation.

Best regards,
Hannes

[dips]

Hi Hannes,
We tend to only install what is needed on a server to reduce the attack surface. So for example, if we don't use AWS, there is no requirement for it to be installed as it will never be used.
I get where you are coming from regarding the option to simplify installation but perhaps there should be an option in the installer to view more options and select which Explorers to install.

[BackupBytesTim]

To add a use case, I've had some scenarios with VBR servers in customer's environments where they've had much more limited space available on their servers and removing all the extra explorers and the agents was desired for the disk space savings. Especially useful because VBR seems to require a large (12+ GB) amount of space to install an update, which has resulted in update blocking issues for some customers.

[m.novelli]

+1 I totally agree, also what is the meaning of loading "Veeam AWS Services, Veeam Azure Service, Veeam GCP Service, Veeam Kubernetes Service etc"

They are mostly useless in the SMB Market but they have load on the Server and the ISO size download

Marco

[Gostev]

The idea is to have them readily available for when/if a customer decides to give them a try in the future. They are not creating any load on the Server when they are not used, and they are quite small in size.

Now, I would agree that our ISO size could indeed use some optimizations and this bothered me personally for quite a while. So I'm happy to say that much work has been done in this regard in 12.1 already for some significant reductions. Having said that, the above-mentioned components are nowhere near the "top offenders" still remaining after those 12.1 optimizations.

[BackupBytesTim]

As a feature request, I wouldn't mind seeing said "extra" components handled the way Acronis does things, after the basic Agent is installed Acronis will selectively download and install additional components if the backup job settings require them, the additional components with Acronis are different than the components with Veeam, and of course with Veeam that would be with the VBR server because the Agent and VBR is separate software in Veeam, but the same general concept applies of downloading on-demand when said features are enabled.

That would keep the initial installation simple, but also avoid installing additional unnecessary components, which would keep the "attack surface" smaller and the disk usage lower. Also could speed up the installation time too, I've long been unhappy with VBR's hour+ installation times compared with other software that installs in just a few minutes.

[Gostev]

Well, perhaps Acronis targets SMB where downloading additional components from Internet is not a problem. We target Enterprise where many customers have dark sites, especially these days... which is why we include all components in the ISO.

Just checked with QA and 12.1 takes 10 min to install in their lab.

[BackupBytesTim]

@Gostev I do get that about many enterprise companies having "dark" sites, and for a direct comparison, Acronis does also have the option to install the additional components manually at installation time, or later on using the graphical installer or the command-line installer that remains present on the computer post-installation, and they even provide specific commands in the documentation to install components afterwards, so scripting the installation of additional components post initial install is simple.

It's not a big deal for us to remove unnecessary components, but some additional options would be nice. There definitely seem to be some options that Veeam could implement. Perhaps for consideration in V13.

On the topic of QA's install time, I'm curious what sort of hardware they run that test on, and if it's inside a VM as recommended in the docs or on a physical installation?

[Gostev]

Since these are QA labs, they use VMs almost exclusively of course.

However, I need to correct you in that it's actually NOT recommended to run a backup server inside a VM, at least not when protecting a production virtual environment - because the first rule of backup/DR is that a backup system should not rely on a system it is designed to protect in any way. For smaller environments, the best way is to have all-in-one install on a physical server.

[mikeely]

Honestly, it would be nice to have a simple "Default Install/Advanced Install" step when running the installer. Additionally, if someone at a dark site decides to try one of the additional components (although I can't imagine why a dark site would need something like the AWS plugin), by the time they made that decision the plugin would likely be out of date and need an upgrade anyhow.
Personally, I find it tedious to have to stop a zillion "Veeam*" services when trying to do maintenance - especially when I can't just call wmic service where "name like 'Veeam%%%'" call stopservice because I need to keep one component running.
It's kind of like the number of ports Veeam requires for talking between Windows machines. It's messy, and doesn't need to be.

[jassonmc]

@Gostev
I totally understand the point of "make it stupid simple" in regards to installation.
But Veeam Backup has become a behemoth in features and size, not everyone needs.
Just looking at the Windows Firewall reveals dozens of rules and most of them simply mean a lot of added attack surface to me.
To protect our SMB customers on Hyper-V, we disable most of them, since they use local backup storage and a distant Windows or Linux backup repository and they do not utilize scripting, nor is any web interface necessary. Backup jobs there are usually setup once and test recovery once a year as there isn't more money for additional services. We have 2FA protected access to the Veeam Backup server via RDP for those logins we need to modify the jobs or fix anything that's broken.

I could also see, that entrprise customers with "black sites" would benefit from this, as it would reduce attack surface also for them.

So +1 from my end to for that feature request

[BackupBytesTim]

However, I need to correct you in that it's actually NOT recommended to run a backup server inside a VM, at least not when protecting a production virtual environment - because the first rule of backup/DR is that a backup system should not rely on a system it is designed to protect in any way. For smaller environments, the best way is to have all-in-one install on a physical server.

Apologies, I verified with members (well, one member) of my team who was with the company when we first got signed up with Veeam (I was not), and while it's not in the official documentation, it was recommended by a Veeam engineer of some sort who was working with us at the time to determine "best practice" for infrastructure designs.

Our situation being, we can't have customers provide dedicated hardware for hosting VBR, so it needs to be installed in the existing environment somewhere, and the recommendation given by Veeam at the time was that it's better to install in a VM than on a system that's used for other things.

I have similarly seen that recommendation from other users on the forums, though aside from potential Windows licensing concerns dependent on the specific situation, I don't see why that would be a good recommendation. Installing on a Hyper-V host (for instance) seems perfectly reasonable to me, hypothetically all backup data transfer for VMs goes through the Hyper-V host anyways, because it's hosting them, so I'm not sure why that would have been deemed a poor design at the time. But, there does seem to be nothing one way or another in the Veeam docs that I could find easily.

So on the topic of the extremely lengthy installation times, our standard practice of creating a new VM and installing it in the VM does seem to be a big issue there, and I've thought of it as an issue from the beginning, seems like a somewhat extreme modification to the customer's environment vs just installing VBR directly, but it does appear to be more a recommendation given by Veeam, not an officially documented requirement. So I'll probably suggest doing differently next time we set it up somewhere.

[YouGotServered]

I think we are conflating the "don't install Veeam in a VM" statement with "don't install Veeam on a VM that is sitting on the virtual infrastructure that you want to protect" statement. Both are completely different. It's totally fine to have a virtualized Veeam server as long as it is on a separate host NOT inside the same vCenter / management scope as your production.

[tyler-no-work]

I would really like the option to not install features, which would be intuitive in the install wizard, rather than going back to remove features later.
*edited as there are different definitions of dark sites*

[BackupBytesTim]

I think we are conflating the "don't install Veeam in a VM" statement with "don't install Veeam on a VM that is sitting on the virtual infrastructure that you want to protect" statement. Both are completely different. It's totally fine to have a virtualized Veeam server as long as it is on a separate host NOT inside the same vCenter / management scope as your production.

That does makes sense to me. So you wouldn't want to rely on manually setting up a temporary server to recover your backup server to before you recover everything else. In our case specifically though we do often install VBR on a VM in the protected environment, on the same host that has other protected VMs and is usually itself also backed up by the Backup Agent. Most of our customers are small businesses and especially with the "Veeam works in your existing environment" idea in mind, we can't insist that they need to buy an entirely new server to do backups.

My current thought is the next setup we do, and maybe we will try "migrating" an existing server in a lab environment, will be direct on the Hyper-V host. Majority of our VBR servers are for customers using Hyper-V. Will see if that improves things somewhat.

[m.novelli]

I think Gostev (and Veeam Management at all) is focused too much on Enterprise Customers disregarding SMB market and our needs

Veeam follow (too much) the money , like Microsoft , Amazon , Google, SAP, Oracle...
IT costs are becoming unsustainable, I hope in some kind of reset in the next 3 - 5 years

Marco

[ITP-Stan]

I don't think that installing on the Hyper-V host is a good idea.
In a VM you can set the amount of RAM and CPU you want to assign.
You can also reboot that VM to do OS or software maintenance.
On the Hyper-V host itself, you probably can't reboot easily, you risk using to much RAM (memory leak perhaps) and impacting your production VM's.

So in small environments, a VM on the production hypervisor seems reasonable to me.
If possible I would use a dedicated datastore. For instance a separate SSD in the host.

And since we are talking about two seperate things in this topic all at once.
+1 for the ability to not install certain components that we don't need, such as GCP, Azure, Karsten, ...

[JGM2023]

+1 From an Enterprise Customer, We often have Issues with Inconsistent versions of these plugins across our VBRs (Due to Hotfixes, patches etc), So having a tick-box to enable/disable these features on Installation, and also enable them after Installation would also be useful.

[BackupBytesTim]

I think Gostev (and Veeam Management at all) is focused too much on Enterprise Customers disregarding SMB market and our needs

Veeam follow (too much) the money , like Microsoft , Amazon , Google, SAP, Oracle...
IT costs are becoming unsustainable, I hope in some kind of reset in the next 3 - 5 years

Marco

Totally agree on that point, and I can name a few other forums users who have shared the same opinion. I understand "business is business" and Veeam needs to make money, but other companies manage to provide functionality and support in consideration of smaller companies and (more importantly) service providers servicing smaller companies.

[mkaec]

+1 on the feature request. I would also enjoy being able to bypass installing features I know for sure will never be used.

[tgx]

+1 on not installing unnecessary apps and services.

[janezk]

+1 on feature request. We have everything on-prem and no data in the public cloud, and also won't be any time soon, probably never. So all "multicloud" stuff is unnecessary for us, it increases attack surface, that is already big with all the ports, that have to be opened.
Regarding the required ports... There is such a huge table of required ports, that opening the right ports is a big pain... Especially knowing that you have to deal with networking guys...
I'm aware of the Veeam ports mapper tool on https://www.veeambp.com/ports/ but is not very user frendly for input of data and also the output is very bulky... I can't give it diretly to the networking guys as it requires a lot of manual "optimization"... I hope it will be "upgraded" in the "Veeam style"

[sandsturm]

+1 on feature request. We also have an enterprise environment with a lot of regulations and security guidelines, and not having unused services installed helps a lot in keeping operational effort on a low level. We always have to justify why a specific service is running on a machine to our security department, especially if services are named as ...Azure... or ...AWS... or similiar

thx,
sandsturm

[m.novelli]

So it seems this is a feature request both for SMB and Enterprise Customers!

Marco