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 master 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 backup image prior to that 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.Ensure that the user that you have added using the tpconfig command has access to the entire MongoDB cluster and the custom folder paths that are specified in the
mongodb.conffile.For MongoDB 4.2 sharded clusters, ensure that the Feature Compatibility Version (FCV) is same across all the MongoDB cluster nodes. This step ensures data consistency during backups.
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 incremental backups for MongoDB 4.2 sharded clusters only if the Feature Compatibility Version (FCV) is set to 4.0 or earlier. If your MongoDB 4.2 sharded cluster has FCV 4.2, then only full backups are supported.
NetBackup supports full backup only for mongodb 4.4 version on sharded cluster.