The article directly follows Veeam Backup & Replication - upgrade to version 13 - part 1.
Operations After Server Upgrade
Updating Components on Servers
We launch Veeam Backup & Replication Console on the server and connect to it.
An update of (remote) components will be offered, which we perform. All Veeam components on remote servers that the Backup Server communicates with must be updated, otherwise they cannot be used in jobs.
VBR Console Upgrade
If we use remote consoles for management, we must update them. If we have console version 12.3.2.4165, the upgrade will be offered automatically after connecting to the server (old console connection occurs on the original port 9392). Local administrator permissions are required; if we don't have them, elevation will be offered.
Components are downloaded, old ones are uninstalled and new ones are installed. After updating the console and launching it, plug-ins were also updated. The upgrade took more than 17 minutes for me.
The new console connects to port 443 and verifies the certificate. By default we have a Self Signed certificate, so we get a warning. We can install a trusted certificate Backup Server Certificate.
Trusted Hosts Hardening
If we have Linux servers in the backup infrastructure and in the settings (Main Menu - Options) security under Linux host authentication (now Host Authentication) the option Add unknown hosts to the list manually (which is the standard setting). Then after the upgrade we must verify that all infrastructure servers are trusted. Trust is now resolved not only for Linux servers.
Right after the upgrade everything looked fine, but after some time the Hyper-V cluster was displayed as untrusted and needed to be approved.
Virtual Lab
The documentation states that if we use Virtual Lab, we should open the settings of each lab and click through the wizard so that the new version of the application proxy is deployed. According to the logs, reconfiguration and uploading of new files actually occurred.
Backup Components on Linux
If some backup infrastructure component runs on Linux and does not have the VMware Backup Proxy role. Then we must click through the settings so that the new Persistent Data Mover is deployed.
Note: It may not be bad to click through the settings of all components. See my problem with Hyper-V at the end of the article.
Agent Upgrade
We can manually start Rescan on the Protection Group or wait for the scheduled one to run. If we have automatic agent updates enabled, the upgrade will occur. Otherwise we must initiate it manually. For me it was an upgrade of Veeam Agent for Microsoft Windows from version 6.3.2.1205 to 13.0.1.120 (13.0.1.1009 for VBR 13.0.1.1071).
Enterprise Plug-Ins Upgrade
To update Veeam Plug-in for Oracle RMAN, we run the installation of the new version on the target server. Currently it is version 13.0.1.180. We can find the necessary files on the installation ISO of Veeam Backup & Replication.
When transitioning to VBR 13 and Oracle on Linux, we must first install the package veeam-openssl3-3.0.0.31-1.x86_64.rpm, which we find in the \Packages folder. Then the Plug-in itself VeeamPluginforOracleRMAN-13.0.1.180-1.x86_64.rpm from \Plugins\Oracle RMAN.
If Veeam Agent is also installed on the server, we can upgrade remotely from the console. It should work through Protection Group or by right-clicking directly on the server and choosing Plug-in - Upgrade.
Enabling Jobs
Finally, we enable all scheduled jobs that we disabled before the upgrade.
Upgrade Veeam Hardened Repository
If you are using a managed Hardened Repository installed from VHR ISO 2.0, you can also upgrade VHR after upgrading VBR. The article Veeam Hardened Repository Part 5 - Upgrade from ISO 2.0 to Veeam Infrastructure Appliance describes it in detail.
Troubleshooting
After upgrading Veeam Backup & Replication to version 13, I encountered two minor problems that were quickly resolved.
MFA Blocking Virtualization Platforms and Cloud Plug-Ins
After upgrading to VBR 13, warnings started being logged in the Backup Configuration Job about connection problems to AWS and Microsoft Azure plug-in.
Warning : Failed to connect to AWS plug-in: Failed to login to platform service (ID: [9a8806c7-85c8-4ecd-8eea-f6fde055e802]): Warning : Failed to connect to Microsoft Azure plug-in: Failed to login to platform service (ID: [89622f35-9e48-424b-9d52-a74dc03b65c2]):
Also in Inventory - Virtual Infrastructure, only VMware vSphere and Microsoft Hyper-V were visible, Nutanix AHV, Proxmox VE, oVirt KVM and Scale Computing HyperCore were not displayed. Veeam states in the KB that this is a problem with platforms that are added to VBR using a Plug-In module.
I additionally found another error in the log. In History - System there is a Shell run job, where finding 6 add-ins was indicated, but all had not found errors.
Succeeded : Found 6 add-ins Failed : Loading console extension: AHV plugin Error: Platform service returns invalid code: NotFound Failed : Loading console extension: AWS plugin Error: Platform service returns invalid code: NotFound Failed : Loading console extension: Microsoft Azure plugin Error: Platform service returns invalid code: NotFound Failed : Loading console extension: Kasten plugin Error: Platform service returns invalid code: NotFound Failed : Loading console extension: PVE plugin Error: Platform service returns invalid code: NotFound Failed : Loading console extension: KVM plugin Error: Platform service returns invalid code: NotFound
On the Veeam forum I found a link to KB4678 and the first listed solution solved my problems. It concerns the situation when we have MFA enabled (Multi-Factor Authentication) for user login. We must add (Main Menu - Users and Roles) the system account NT AUTHORITY\SYSTEM as Veeam Backup Administrator with MFA disabled (This is a service account). Subsequently, it is necessary to restart Veeam Backup Server.
Problem with Guest Processing on Hyper-V
I also encountered one more problem. Only on one Windows VM running on Hyper-V, it failed to connect to the OS so that Application-Aware Processing could occur.
Succeeded : Failed to connect to guest agent via GIP, failing over to guest agent connection through PowerShell Direct Succeeded : Failed to connect to guest agent through PowerShell Direct, failing over to guest agent connection Warning : Unable to perform application-aware processing because connection to the guest could not be established Warning : Unable to process Microsoft SQL Server transaction logs because connection to the guest could not be established
When I tried Verify network connectivity and credentials within the backup job settings and Guest Processing. An error appeared that gave a bit of a clue.
Failed : Connecting to guest OS via Guest agent (0:00:08) Failed : Testing host accessibility via Guest agent (0:00:08) Failed : Failed to connect via Guest agent. Host: [servername]. (Failed to create file system ops via DeploymentSvc) ([servername] Failed to discover Installer service.) (Unable to use the existing installer service nor to install a new one);
I manually installed Veeam Installer Service on the server using VeeamInstallerSvc.msi. On the next run, the backup passed without problems.
I also noticed information (which appeared for multiple VMs) about connection problems to the host using Guest Interaction Proxy (GIP) or problems with deploying guest runtime components using GIP.
Succeeded : Failed to connect to guest agent via GIP, failing over to guest agent connection through PowerShell Direct Succeeded : Failed to inject guest runtime components via GIP, failing over to guest agent connection via GIP
I opened the settings of our System Center Virtual Machine Manager (SCVMM) server in Backup Infrastructure and clicked through the wizard. It turned out that Guest Interaction Proxy installation was in progress on all Hyper-V servers. After that, the error above was no longer displayed.
Missing Immutable Until column for Backups
I additionally noticed that since the upgrade, information about how long backups are immutable is not displayed in the Veeam Backup & Replication Console. For backups (Home - Backups) stored on Veeam Hardened Repository, the Immutable Until column has disappeared. However, in VBR 13 there is a new feature that the immutability information is displayed for backups stored on object storage. For these backups, the Immutable Until column is present.
I contacted Veeam Support, where they responded immediately. This is a known issue caused by a flaw in a stored procedure on Microsoft SQL Server that retrieves backup properties. They sent me a procedure and SQL script that fixed the procedure.
There are no comments yet.