Just a Routine Upgrade … ;-)
We recently upgraded a customer’s Veeam Software Appliance (VSA) from version 13.0 to 13.1. The upgrade itself went through without a hitch – which is exactly how the VSA is designed to work: the appliance ships its own updates and handles the operating system and Veeam components in one go, without you having to worry about dependencies. But right afterwards, every server based on the Veeam Infrastructure Appliance (VIA) was offline – along with every role running on them, whether repository, proxy or mount server. No need to panic: this is expected behavior – and it affects not only the VSA, but classic VBR servers on Windows just the same. So nobody wastes time troubleshooting during their next upgrade, here’s the explanation and the fix.
What exactly happens?
After upgrading the backup server to 13.1 – whether VSA or Windows – the VIA servers still on version 13.0 can no longer connect to the backup server. In the console, the VIA servers – and with them every role they host, such as repositories and proxies – show up as unavailable. Backup jobs relying on these components obviously can’t run in this state. This shouldn’t come as a surprise, though: the updater or upgrade wizard explicitly points out before the upgrade that the Infrastructure Appliance servers need to be upgraded as well. So don’t just click that notice away.
The cause: a new .NET and OS foundation
With V13.1, Veeam has significantly modernized the platform under the hood. The change affects both the .NET runtime and the appliances’ underlying operating system:
| Version | .NET | Operating system (Rocky-based) |
|---|---|---|
| V13.0 | .NET 8 | Rocky Linux 9.2 |
| V13.1 | .NET 10 | Rocky Linux 9.6 (Veeam JeOS 9.6) |
Since .NET 10 requires Rocky 9.6, a VIA running version 13.0 is simply not compatible with a 13.1 backup server. The components must be brought to the same level. It doesn’t matter whether the backup server runs as a VSA or on Windows: on a Windows VBR server, the upgrade wizard installs .NET 10 (Microsoft .NET 10.0.10 Windows Server Hosting) automatically, while the OS upgrade to Rocky 9.6 only applies to the appliances. Either way, the VIA servers have to be upgraded too.
The fix: upgrade via “Managed Servers”
The good news: this can be solved with built-in tools. Under Managed Servers in the backup console – on the VSA as well as on a Windows VBR server – you can trigger the upgrade of the VIA servers automatically. The appliance takes care of the component and operating system update itself. Once finished, the VIA servers are reachable again and all their roles are available as usual.
Planning tips
- Schedule a maintenance window: Between upgrading the backup server and completing the VIA upgrades, the affected VIA servers and all their roles are offline. Backup jobs relying on them simply cannot run during this time – so schedule the maintenance window in a way that no backups are missed.
- Treat the upgrade as one package: Updating the backup server – VSA or Windows – is only half the job. The VIA upgrades belong in the same change.
- Mind the bandwidth to remote sites: The VIA update includes a major operating system upgrade. At remote sites with limited WAN bandwidth, the download can take a while. Since all VIA servers must be upgraded at the same time after the backup server upgrade, plan extra time for the maintenance window accordingly. According to Veeam, V13.1 also allows Enterprise Manager to act as an update mirror – worth a look for distributed environments.
Conclusion
Offline VIA servers right after upgrading to V13.1 aren’t a bug, but a consequence of the platform switch to .NET 10 and Rocky 9.6. If you know this, you’ll plan the VIA upgrades in from the start and spare yourself the moment of panic after updating the backup server – whether VSA or Windows.
*first picture is AI created
Original Post is on my blog: Veeam V13.1: VIA Servers Offline After the Veeam Upgrade from V13.0? No Need to Worry - petersvirtualworld.de