Issue/Introduction

Source and classification

• Source: Site case from the veeam &Commvault使用说明 group.
• Classification: Prerequisite component installation or connectivity issue before Veeam backup.
• Confirmation basis: During a Kaspersky Server backup, Veeam reported that data-agent did not pass the health check on 16443 after installation. Another multi-management-node case confirmed that local installation might deploy only on the current node; other nodes do not automatically receive parameters and require deploy.
• Internal tracking: No specific Jira.

Issue metadata

• Issue ID: None.
• Component/product: ZSphere, Veeam Data Agent, and API Proxy deployment components.
• Status: Troubleshooting and a multi-MN workaround are available; determine cause from listener, service log, and connectivity.
• Priority/severity: General; blocks backup on the affected host or VM.
• Confirmed version: Compatible Veeam version 13.1.1.18.
• First fixed version: None.
• Confirmation date: August 13, 2026.
• Last updated: September 4, 2026.

Problem description

Before backup, Veeam installs or checks data-agent on the relevant host and accesses 16443 to confirm readiness. Health check fails if service is not started, the port is not listening, a network/firewall blocks access, or a multi-MN deployment installed the component on another node.

The complete site error is:

2026/8/13 13:55:40 :: Kaspersky Server : Failed to perform backup: host data-agent did not become healthy on 172.27.220.211:16443 after installation

This proves only that Veeam could not confirm readiness on that IP, not whether service startup, installation placement, or network failed. Identify the IP's node, then inspect installation, port, and path.

Symptoms

• Backup fails while installing or checking data-agent.
• Task logs show:

  Failed to perform backup: host data-agent did not become healthy on <IP>:16443 after installation

• Port 16443 might not listen on the addressed node.
• In a multi-MN environment, only the locally installed node might listen.
• Even with a listener, routing, firewall, or wrong address might block Veeam.

Site screenshot

Impact

• Backups using the affected node fail.
• Other correctly deployed and reachable nodes might be unaffected.
• There is no evidence of damage to existing backups or VM disks.
• Repeated installation/uninstall before diagnosis might overwrite logs.

Environment

• Product: ZSphere and Veeam integration.
• Product line: ZVF.
• Component: Veeam Data Agent and related deployment components.
• Confirmed version: Veeam 13.1.1.18; assess other versions separately.
• Trigger: The specified node's data-agent does not pass health check on 16443 after installation, or Veeam cannot reach it.

Possible causes

This symptom can be caused by one or more of the following conditions:

• data-agent or a related service has not finished installing, is still starting, or failed to start, so 16443 is not listening.
• The target listens, but Veeam-to-node routing, firewall, or policy blocks it.
• Local installation in a multi-MN environment did not deploy the component to the addressed node.

Resolution

1. Identify the node for the reported IP

1. Record IP and failure time.
2. Map the IP to its management/service node in ZSphere.
3. Confirm the task should access that node.
4. In a multi-MN environment, do not inspect only the current login/installation node.

2. Check port 16443

Run on the addressed node:

ss -lntp | grep ':16443'

• If listening, test from Veeam.
• If not, inspect installation/startup and errors.

If service name is unknown:

ps -ef | grep -i data-agent
systemctl list-units --type=service | grep -Ei 'data-agent|veeam|api-proxy'

Then inspect the discovered service. Names and paths must come from the current package documentation, not another version.

3. Test from Veeam

On the Veeam server, test port 16443 on the IP from the error:

Test-NetConnection <ip-from-error-message> -Port 16443

Handle the result as follows:

• TcpTestSucceeded=False with no listener: inspect installation/startup.
• Listener exists but remote test fails: inspect routing, access control, and node firewall.
• TCP connects but health still fails: inspect service logs, certificate, and health endpoint response.

4. Verify installation method in a multi-management-node environment

In another case, this local command left only one management node listening:

./install-api-proxy.sh --install

The conclusion was that local installation lacked the parameters required for multi-node deployment and that the package's deploy method should be used.

Therefore, if the addressed IP belongs to another management node on which the component was not installed, proceed as follows:

1. Save output and logs.
2. Check package documentation for multi-MN parameters, VIP, and node list.
3. Use the version's deploy method so every specified node is installed.
4. Check 16443 on every node.
5. Test each node or VIP from Veeam, then rerun backup.

5. Verify after service startup

1. Confirm the service runs on the addressed IP.
2. Confirm 16443 listens.
3. Confirm Veeam connectivity.
4. Verify the health response using package documentation.
5. Rerun backup and confirm no data-agent health error.

6. Collect information if unresolved

If the issue remains after these checks, collect the following information and contact engineering:

• Exact ZSphere, API Proxy, and Veeam versions.
• Veeam task name, failure time, and complete session log.
• Node IP in the error and the role of that node.
• Number of management nodes, VIP configuration, and installation method used.
• ss -lntp | grep ':16443' output from every relevant node.
• data-agent, API Proxy, and installer logs.
• Result of Test-NetConnection from the Veeam server.
• Whether an upgrade, uninstall, reinstallation, or management-node switch occurred before the issue.

Additional information

Precautions

• Kaspersky Server is the name of the backup object that failed; it does not mean that the issue affects only Kaspersky products.
• host data-agent did not become healthy is a health result, not proof of process crash.
• Single-node local installation is only a diagnostic direction from another case; follow it only when the addressed node is undeployed.
• If all nodes listen, do not repeat deploy; investigate network, certificate, and health response.
• Do not disable the whole host firewall. If policy must change, open only the required Veeam-to-node port under site security rules.
• Do not delete service files, uninstall, or modify the database without documentation or development confirmation.

Fix status

• Current status: Diagnostic steps and multi-MN deployment workaround available.
• General fix: There is no evidence that all such errors share a single defect.
• Multi-MN: If local installation missed the target, use the package's deploy method.
• Fixed version: None.
• Related patch/fix package: None.

Related information

• Original error time: August 13, 2026, 13:55:40.
• Original object: Kaspersky Server.
• Original node: 172.27.220.211:16443.
• Multi-MN discussion date: August 31, 2026.
• Source group: veeam &Commvault使用说明.
• Recommended images: Original error found by searching for healthy, plus a comparison showing one management node listening on 16443 and another not listening.