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...
-
hpadm
- Enthusiast
- Posts: 55
- Liked: 11 times
- Joined: May 18, 2021 1:55 pm
- Location: Slovakia
- Contact:
-
david.domask
- Product Manager
- Posts: 3656
- Liked: 888 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: v13 dropped support for existing 32bit agent instances
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.
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.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: No registered users and 3 guests