NetBackup chooses the node in a MongoDB cluster to take a backup in the following order:

If you want NetBackup to select a particular backup node in the MongoDB cluster, set it as a hidden node.

Before you run a backup job, ensure that you get a successful ping response from all the MongoDB nodes on the backup host. Check and update the firewall settings so that the backup hosts can communicate with the MongoDB cluster.

Ensure that the MongoDB cluster that you want to protect lets you take LVM snapshots.

Renaming the volume group or the physical and logical volumes of the LVM for MongoDB database paths causes the backup to fail. If you rename the volume group or the physical and logical volumes of the LVM, ensure that the MongoDB database is mounted on the new path before taking a backup.

The backup shuts down the balancer on the mongos process and blocks all the other operations. Hence, during a backup process, ensure that you do not run any other operation that uses the mongos process. For example, import the database.

Always run a full backup when you make change to the database path, or modify the configuration file for the mongod or the mongos processes, or change the MongoDB topology.

If there are multiple MongoDB clients in a single NetBackup backup policy increase the Client read timeout parameter for primary server, media server, and the client to ensure that the all the backups are successful.

For more information, refer to the NetBackup™ Administrator's Guide, Volume I and the Timeouts properties section.

Incremental backup jobs use consistent backup images as a reference for determining the incremental changes. If the previous backup has failed, or was partially successful (failed for one of the nodes), it is skipped completely and a previous backup image is considered. In such cases, the backup operation can take longer and the image that is created might be of a larger size.

The oplog file has a capped or rolling cache and you can configure the size of the file. NetBackup uses oplog to capture incremental data. Oplog roll-over can cause the incremental backups to fail. To prevent this, make sure that oplog file size is sufficient to hold the incremental data that is generated between the incremental backups.

If the MongoDB cluster is running under the mongod account, we need a non-root sudoer account, and the same needs to be configured as a host user in tpconfig.

If the MongoDB cluster is running under the non-root or root account, then ensure that the host user credentials that are configured using the tpconfig command are of the host user account that is used to configure the MongoDB cluster (MongoDB daemon's host user account that is either root or non-root).

If you are using oplog retention feature on replica set, ensure that the scheduled time between incremental backups is less than the minimum oplog retention period. This ensures capturing the correct incremental backup.

NetBackup supports full backup only for MongoDB 4.4 and later supported versions on sharded cluster.