Prerequisites for backing up a MongoDB cluster
NetBackup chooses the node in a MongoDB cluster to take a backup in the following order:
Active hidden node
Active secondary node
Active primary node
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.
Logical volume requirement for snapshot:
Ensure that the MongoDB database directory is mounted on a logical volume to complete the snapshot operations.
Use the vgdisplay command to ensure that the free physical extent size is sufficient in the logical volume group to complete the snapshot operations.
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
oplogfile has a capped or rolling cache and you can configure the size of the file. NetBackup usesoplogto capture incremental data.Oplogroll-over can cause the incremental backups to fail. To prevent this, make sure thatoplogfile size is sufficient to hold the incremental data that is generated between the incremental backups.If the MongoDB cluster is running under the
mongodaccount, we need a non-root sudoer account, and the same needs to be configured as a host user intpconfig.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
tpconfigcommand 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.