v13 dropped support for existing 32bit agent instances

[hpadm]

I'd like to ask, was there a functional reason for doing this? For 64bit agents on unsupported OS, the updater only shows a warning that they will no longer receive updates, and recommends switching to standalone mode, but doesn't outright imply they'll immediately stop working. For 32bit agents, it straight up wants them removed right then and there. But the existing instances are still working fine with 12.3, and communication with them happens over a network protocol that's presumably bitness independent, so the unsupported 32bit agents should be no different from the unsupported 64bit agents. Yet one passes and the other doesn't. I could understand no longer building and shipping the 32bit agent installer, but to also drop support for existing deployments seems unsubstantiated and gratuitous. The expected approach would have been to retain support until functional changes break compatibility in a way that cannot be handled by a serverside shim or feature flags.

We are contractually required to operate software that is only approved for use on a 32bit windows OS. VBR's efficient block-level differential processing made it possible to back up easily, even in a limited network bandwidth environment. No longer being able to do that means I will need to consider declaring VBR as EoL and slowly look for another product.

Curiously, the updater, after checking my license, suggests switching 64bit clients to standalone mode, even though when I checked some years ago, the community license prohibited mixing deployment types. I wonder if this requirement had been lifted. I also wonder if the 12.3 32bit agent would be able to talk to the 13.0 backup repository gateway if I did switch it to standalone mode...

[david.domask]

Hi hpadm,

Resources mainly -- maintaining functionality requires fairly extensive testing, and v13 brought many architectural changes that would need further development to support these older agents.

Your situation is understood, and what I can recommend is to use standalone agents and target a network share (NFS / SMB) for the repository.

[hpadm]

In a lab test, I have determined that adding a 12.3 32bit host into a 13.0 protection group will show failure during rescan. The host cannot be managed this way anymore. The rescan tries to deploy a 32to64 bootstrapper which will then reinstall the 64bit version of the agent, even though it should know that it'll fail because the host can't run 64bit code. I guess this is intended for agents that were somehow installed as 32bit on a 64bit OS (even though the current installer prohibits that).

However, adding it as an unmanaged host backed up by an agent policy job still works. It can still target a veeam backup gateway, it shows up in the VBR console UI and even though it cannot be configured from there, it can at least be monitored and its jobs and backup files become available. The backup chain gets broken but it's not a huge deal.

Also, I took a look at Server2012R2. VBR doesn't want it as a managed server anymore, and the installer/updater will not proceed until it is removed from this role. However, it can be smuggled back in via VBR Configuration Restore. The only updated component that's failing is Mount Service (exception at startup) which can be worked around mid-install by retargeting the service to a copied v12.3 folder. That will allow the server to continue to be used as infrastructure, but a few specific actions have a hardcoded version check that interferes with full use.

I feel this was unnecessary and could have be solved by fixibg the crash. You also jumped the gun a bit since 2012R2 ESU3 still has half a year left and is actively receiving monthly security updates. And one does not simply update windows server, the model is to throw away all the core, system and user licenses along with the hardware and buy a whole new set at full price. It is much cheaper to not do that. But hey, I don't have insight into the inner workings of Veeam, it's possible this version was causing so many issues in advanced scenarios that ditching it was a priority.

[hpadm]

* Just adding for completeness that while the workaround described above satisfies the up-to-date requirement, Mount Service 12.3 does not seem compatible with 13.0 infrastructure (VeeamRestoreService rpc not found / responding). This can be dealt with by designating another compatible host as the mount server instead. I suspect this will create a data flow inefficiency if this server is both the repository gateway and the FLR destination, but oh well.