On 6 September, my lab Veeam Software Appliance (build 13.1.1.18) installed a mandatory system and security update, restarted its services, and rebooted itself. Two clicks, one confirmation, and the appliance handled the rest. No ISO, no installer wizard, no shell session.
This quick blog post shows how easy it is to update your Veeam Backup Server using the Veeam v13 Appliance and why you should migrate to a hardened appliance.
Update handling on the appliance is handled by Veeam Updater, a service that runs on the appliance itself and talks to repository.veeam.com. According to the Veeam documentation, it polls every 12 hours, stores what it finds in a local service database, and updates and restarts itself first if a newer Updater component is available. The same check runs when you click Check for updates in the UI.
Two entry points, one page
The Windows-based backup console now has an Updates branch under the Home menu, with Check for Updates, Update Components, Missing Updates, and Update Settings. Check for Updates opens the Updater web UI in a browser.
You can access the web UI from Configuration > About > Updater interface, next to the product build number.
Both land in the same place, https://FQDN/updater/updates.
The single pending item was labeled as system and security updates, mandatory, with the date it would be installed automatically printed next to it. That date is the compliance deadline doing its job, and it is the part of this design most people will want to understand before they deploy the appliance.
What is actually in the bundle
Next to the update list there is a What’s new link, and it is worth opening before you click install. It breaks the set down package by package with the version you are on, the version you are going to, the download size, and a one-line description, each with its own Details link.
My pending set came to 796 MB and mixed both layers in one mandatory item. Operating system packages such as iscsi-initiator-utils and isns-utils-libs, PowerShell moving from 7.6.5 to 7.6.6, and Veeam components including veeam-platform-service-azure going from 13.9.0.354 to 13.9.1.407.
The _ciq suffix on the OS package versions is not cosmetic. Veeam JeOS, the operating system under the appliance, is built on Rocky Linux from CIQ under RLC Pro, which Veeam’s system requirements describe as providing long-term support and FIPS 140-3 validated packages. So the OS packages arriving here are not community Rocky builds picked up from a public mirror; they come through a supported channel with the product.
This panel is a summary, not release documentation. For what a Veeam build actually changes, go to the release notes and the What’s New document for that version. What the panel gives you is the thing a change record needs: exact package versions, before and after, on the night you installed them.
Before the install starts, the Updater recommends running a configuration backup and warns that the host reboots automatically if the update requires it. Take the first suggestion seriously. A configuration backup costs seconds, and the appliance is the one component you cannot rebuild from another appliance.
What the run actually did
The session log is granular enough to be useful:
- 12:03, downloading update packages, 24 seconds
- 12:04, validating package dependencies, 13 seconds
- 12:04, stopping core services, 41 seconds
- 12:05, stopping auxiliary services, 1 second
- 12:05, installing update packages, 1 minute 43 seconds
The History tab holds the closed session, one row per update run, with the full step list. This one finished with two steps the live view had not reached yet: restarting system services, then a server reboot. Every step reported Success.
Core services come down before packages are applied, and the appliance rebooted itself at the end, so treat an update window as a full outage on the backup server rather than a brief service restart.
Afterward, the Updates tab reported the system as up to date. In the bottom left, there is an Upload a hotfix option, which is how a private fix from Veeam Support gets applied by hand. That path also matters for appliances with no route to repository.veeam.com, where the alternative is a local update repository mirror.
+The parts you do not control
The documented model is explicit. Operating system and security updates, and Veeam Backup and Replication security updates, are mandatory and cannot be skipped or canceled. Major releases, minor releases, and private fixes are optional and off by default.
What you can configure in the Host Management console or through the global update configuration in the console and web UI:
- which updates install automatically, security only by default, optionally including non-major updates
- a weekly or monthly maintenance window, or None if you want to install manually
- a compliance deadline, 30 days by default, up to 90
Setting the maintenance window to None does not opt you out. When the compliance deadline is reached, the selected updates are installed anyway, and Veeam documents that a forced installation can begin while jobs are running, with recovery operations in those jobs failing as a result. So the real decision is not whether the appliance patches itself, it is which night of which week it does so. Pick the window deliberately and align it with the backup schedule.
One related change in 13.1: Veeam Updater is now installed on Windows-based deployments as well, new and upgraded, and Veeam states the service cannot be disabled there either (KB4840). The appliance behavior is the model the rest of the product line is moving toward.
Besides the new update areas and how we now update our Veeam Backup Server(in this case, the Appliance), we still continue to have the information about missing updates inside our Veeam Backup Server.
What changes when the backup server is an appliance
Run Veeam Backup and Replication on Windows, and you carry two patch streams. The operating system is yours, patched with whatever tooling the rest of the Windows estate uses, on its own schedule, under its own change record, and usually its own team. Product patches arrive separately from Veeam. Two cycles, two owners, and in most environments I have seen, the OS one on backup servers is the cycle that slips.
The appliance removes one of them. Veeam installs Rocky Linux with predefined settings, including volume partitioning and account creation, and the documentation states plainly that you cannot install third-party software on a Veeam Software Appliance. KB4772 goes further: extra Linux packages, third-party applications, or OS settings changed outside the Host Management console put the appliance outside support. You don’t own the operating system, so you don’t have a second patch cycle to schedule, chase, or defend in an audit.
That is what the run above is really showing. One click took both layers, the Rocky Linux packages and the Veeam security fixes, through a single session with a single deadline and a single history entry. No Linux knowledge was needed at any point, which matters for the many teams that stayed on Windows because nobody wanted to own a Linux backup server.
The same closure that removes the burden also removes your agents. If policy requires endpoint detection, vulnerability scanning, or a monitoring agent on every server, the appliance doesn’t meet it by construction, and your argument to the security team is the pre-hardened base plus vendor-controlled patching with an enforced deadline. That conversation is worth having before deployment, not after.
Conclusion
The update screen doesn’t deserve the verdict. The appliance does. Deploying a Veeam Software Appliance means handing the operating system lifecycle to Veeam: their Rocky build from CIQ, their package set, their deadline, with 30 to 90 days of discretion left to you and no shell to fall back on. For most teams, that is a good trade. Patch latency on backup infrastructure has been a long-standing weakness in this industry, and the appliance removes the two excuses behind it: no time and no Linux skills.
The cost lands elsewhere: availability. The appliance stops its own services and reboots itself when an update calls for it. Veeam documents that neither third-party software nor Veeam Agent for Linux can back up or restore a Veeam Software Appliance, and points to the High Availability Cluster feature as the way to keep it available. Put those two facts together, and the self-patching model stops being a convenience feature. A single appliance is a backup server that will take itself offline on a date it chose, with no in-place restore path if the update goes badly. Configuration backups and an HA cluster are what turn that from a risk into a maintenance event.
So the design decision that follows from this post is not whether to let the appliance patch itself. You do not get that choice. It is whether the backup server goes in as a pair before it carries production, and where the configuration backup lands so it survives the appliance it came from. I am building the HA cluster in the lab next, and after that, the update repository mirror for appliances with no route to repository.veeam.com, which is the shape most service providers will end up running. The one measurement I still want from a live system is what a forced install does to a restore that is already in flight.
Reference documentation: Updating Veeam Appliances, How Updates Work, Configuring Updates, KB4840, Considerations and Limitations, KB4772, System Requirements, KB4738.
Share this article if you think it is worth sharing. If you have any questions or comments, leave them here or contact me on Twitter (yes, for me it’s not X, but still Twitter) or LinkedIn, since I am getting off Twitter.
