NetBackup MongoDB Errors 6601, 6625, 6654

NetBackup MongoDB errors 6601, 6625, and 6654 should not be treated as one generic database failure. Recent administrator cases show failures moving as credentials and host configuration change, while Veritas documentation shows that MongoDB authentication, host authentication, naming, RSA keys, backup hosts, and policy configuration are separate layers.

The practical troubleshooting rule is to identify which layer failed before changing another one. One administrator saw status 6625 disappear after changing the host credentials used with tpconfig, only to remain blocked by status 6601. Another saw status 6654, “Unable to retrieve credentials,” even after disabling MongoDB security and choosing No Authentication. Those details are clues, not proof of a single shared root cause.

Why can status 6654 happen even with MongoDB No Authentication?

Status 6654 can still be a credential problem because NetBackup's No Authentication mode does not mean “no credentials anywhere.” Veritas documents a credential file for the NOAUTH case that still contains HostUser, HostPassword, and HostRsaKey for the MongoDB node.

That distinction explains why turning off MongoDB authentication may fail to change the error. Database authentication and host access are different. NetBackup still needs a trusted way to reach and operate on the MongoDB host. If that host identity is missing, mismatched, or stored under a different hostname than the policy expects, the database can be wide open and the backup can still fail.

Veritas also documents a specific status 6654 case caused by inconsistent host naming. Credentials were stored using one form of the hostname while policy or configuration used another. A short hostname in one place and an FQDN in another was enough to break credential retrieval.

So the first 6654 check is boring but valuable: write down the exact host strings used in tpconfig, the backup policy, the client's NetBackup identity, and mongodb.conf. They should describe the same node consistently.

What should be checked in tpconfig first?

The tpconfig entry should be checked for the correct application server, authentication type, host user, RSA key, and exact hostname format. Veritas says the MongoDB node credentials are added for the application server specified in the Clients tab of the backup policy.

For a replica set or standalone deployment, the credential configuration identifies the mongod hostname and port. A sharded cluster may include multiple mongod and mongos endpoints. If the policy says one name while credentials are associated with another, NetBackup can look in the wrong place even though both names resolve in DNS.

The host user matters too. Current Veritas guidance for clusters running under a mongod service account says not to use the mongod service account itself as the host user in tpconfig. It recommends a sudo-capable non-root host account with a home directory and ownership of directories referenced in mongodb.conf.

That makes the “root fixed one error” observation from the administrator case understandable without turning root into a recommendation. Root may have removed a permissions obstacle, causing status 6625 to disappear. The safer long-term task is to determine which permission the intended host account lacks and configure the supported non-root model correctly.

What do status 6601 and 6625 tell you in the reported case?

In the reported case, status 6625 disappearing after a credential change tells you the configuration change affected the failure path. It does not establish that every status 6625 event is caused by the same permission problem, and the discussion did not provide enough evidence to define status 6601's root cause.

That is exactly why troubleshooting should preserve each test result. Record the initial error, change one variable, rerun the same backup, and note whether the status changes. If 6625 becomes 6601, the system progressed far enough to encounter a different condition. Rolling several configuration changes together destroys that evidence.

Useful checks include the exact NetBackup and MongoDB versions, MongoDB topology, the selected policy type, backup host, plug-in deployment state, mongodb.conf, the credential entry, the host RSA key, hostname consistency, and permissions on every directory NetBackup needs to use.

If MongoDB runs inside a virtual machine, keep the application problem separate from machine protection. The Proxmox backup comparison illustrates the broader difference between protecting a VM as an object and protecting the application state inside it. A VM recovery point does not answer every database recovery question.

Does the NetBackup client need to be on the MongoDB server?

A NetBackup client is not automatically required on every MongoDB node simply because a backup is failing. The correct architecture depends on the MongoDB plug-in workflow and NetBackup version, including which system acts as a backup host.

Veritas documentation explicitly describes a NetBackup client as a possible backup host. When a client is used in that role, it must be included in the primary server's allowed list with the APP_PROXY_SERVER configuration. That is different from saying “install the client everywhere.”

This distinction matters because adding software to the database server can create the illusion of progress while leaving the real configuration error untouched. Before installing another client, map the supported flow: primary server, backup host, MongoDB node, plug-in, credentials, policy, and data path. Then verify which component belongs on which machine for the exact NetBackup release.

The same recovery-layer thinking appears in the Proxmox Backup Server guide. Host protection and application-aware recovery solve related problems, but they are not interchangeable.

How should hostname mismatches be tested?

Hostname mismatches should be tested by comparing literal strings, not by proving that DNS resolves. Resolution only proves that a name points somewhere. NetBackup credential lookup may still depend on the identity string used when credentials were stored.

Start with the application server value in the policy. Compare it with the hostname used in tpconfig. Compare both with the client name and every hostname in mongodb.conf. If the environment standard is FQDN, use the FQDN consistently. If a documented workflow expects a short name, use that consistently instead.

Then verify forward and reverse resolution from the systems participating in the backup. Check that there are no duplicate aliases pointing to different interfaces or stale records. If the node was renamed, confirm the NetBackup configuration was updated instead of relying on DNS aliases to hide the difference.

This is one of those failures where “networking works” can be true and the backup can still be wrong.

What is the safest troubleshooting order?

The safest order is identity first, then plug-in placement, then policy and application configuration, then data movement. Confirm supported versions and topology. Confirm the exact MongoDB nodes. Confirm hostnames. Confirm tpconfig credentials and RSA keys. Confirm the host user meets the documented requirements. Confirm mongodb.conf paths and ownership. Confirm the chosen backup host is allowed by the primary server. Only then widen the search into network, storage, and application behavior.

Do not disable MongoDB security as the first troubleshooting step. The status 6654 case shows why that can waste time. NOAUTH still leaves NetBackup host credentials in the path, and removing database authentication creates a new security state without proving anything about the host identity NetBackup is trying to retrieve.

I would also avoid keeping root as a permanent workaround merely because one error code disappears. Use it as evidence that permissions matter, then move toward the least privileged host account the NetBackup MongoDB guide supports.

The goal is not to make one job turn green by any means available. It is to understand which identity, host, and configuration NetBackup is using so the fix remains predictable when the next node, replica set, or restore operation is added.