Prerequisites and the best practices for protecting MongoDB
For sharded MongoDB clusters, mongos and mongod processes must be running on the application server that is specified as the client in the backup policy.
Only RHEL and SUSE platforms are supported for backup hosts.
The NetBackup for MongoDB plug-in requires that the NetBackup primary server, media server, and the backup host are on NetBackup version 8.2 or later.
Verify that NetBackup supports the MongoDB version that you have. For more information, refer to the Software Compatibility List.
NetBackup supports the MongoDB clusters that are configured or installed on RHEL, SUSE, and Linux-s390x, IBMzSeriesRedHat operating systems.
NetBackup supports the following MongoDB configurations:
Sharded MongoDB cluster (MongoDB cluster with configuration server and shards)
Replica set MongoDB cluster
Standalone MongoDB without replica sets
NetBackup supports the following authentication types for MongoDB:
No authentication
Simple authentication
Certificate-based authentication
NetBackup supports the following file systems for backup and restore:
XFS
ext4
Install OpenSSH packages on all the MongoDB nodes. Enable SSH on all the MongoDB nodes.
NetBackup supports the MongoDB clusters that are configured with the WiredTiger storage engine.
NetBackup protects the MongoDB clusters that are configured or installed locally using the
.tarfiles or installed using the MongoDB official repositories.NetBackup supports the Differential Incremental backup for MongoDB along with a Full Backup. Cumulative Incremental backups are not supported currently.
NetBackup recommends that you have at least three configuration servers in your sharded MongoDB environment to support high availability of the backups.
Do not install the MongoDB plug-in on a server that also has the MongoDB application. A server that has the MongoDB application cannot be used as a backup host.
Ensure that the local time on the MongoDB server and the backup host are synchronized with the NTP server.
For sharded MongoDB clusters, the query router role must be present on the config server.
For the MongoDB cluster that has a SUSE operating system, on all the MongoDB nodes set the PasswordAuthentication field to Yes in the
/etc/ssh/sshd_configfile.After you update the file, restart sshd.
Ensure that all the clusters support the same hash key algorithm (RSA).
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).
For more details, See Using a non-root user as a host user.
To protect MongoDB version 4.2, upgrade the NetBackup backup hosts that you have defined in the backup policy to version 9.0 along with NetBackup primary and media server. Backup host versions earlier than 9.0 can affect the MongoDB 4.2 cluster.
Ensure that the ss command is available on the MongoDB nodes. The ss command is required to identify the MongoDB clusters that are created using an externally sourced configuration file.
To protect MongoDB version 4.2, upgrade the NetBackup backup hosts that you have defined in the backup policy to version 9.0 along with NetBackup primary and media server. Backup host versions earlier than 9.0 can affect the MongoDB 4.2 cluster.
If you use a NetBackup client as a backup host, ensure to add the following value in the
bp.conffile of the NetBackup primary server:APP_PROXY_SERVER=NBU_CLIENT_FQDNIf the MongoDB host user does not have root permissions, ensure that the user has access to all the temporary paths to copy the thin client (
mdbserver), logs, snapshots, etc. Add the non-root user to thesudoersfile in the operating system.If you install the MongoDB using the
.tarfile or to a non-default location, add the path of the MongoDB bin folder in thebashrcfile of the operating system to ensure that you can run the MongoDB commands from the CLI.If your MongoDB server uses the SUSE 12.3 operating system, ensure that you can connect to mongod and mongos process with the --host <FQDN> option. For more information, refer to the MongoDB Administrator's Guide.
When you use the -host_password option with the tpconfig command and
mongodb.confHostPassword, ensure that the password:Does not exceed 63 characters
Contains one or more alphanumeric characters: a-z, A-Z, 0-9
Contains one or more of the following characters: - (hyphen), _ (underscore), ,(comma), . (period), ? (question mark)
When you define the paths for logs, thin clients (
mdbserver), snapshots, or anything else in themongodb.conffile, ensure that the host user in the credentials file has valid permissions to access these paths.To enable SSH, add the following entry in the sudoers file:
Default <host_user> !requiretty
Ensure that the MongoDB limits and thresholds are as per the official MongoDB guidelines.
Ensure that the host name is consistently used in the tpconfig command, during the policy configuration, and in the
mongodb.conffile. For example, if you use the FQDN, use it for all host name instances instead of short names.Ensure that application_server matches with the host name that is used in the MongoDB environment and verified using the db.hostInfo() command.
For example, the host name value that displayed by db.hostInfo():
"hostname" : "<hostname_value>:<port>"
Ensure that there are no JSON format errors or typos in the
mongodb.conffile before you run a backup or restore job.Ensure that the path of the security certificates that are added in the
mongod.conffile and used with the tpconfig command are the same for all the MongoDB nodes.For simple authentication, configure the same user who is part of the root group from the admin database for every MongoDB node.
If you use the
mongod.confor themongos.conffile to start the MongoDB processes, run themongodfile using the absolute system path on the MongoDB cluster. For example, use the following command:mongod --config /home/user1/mongod.conf
NetBackup recommends that you run a full backup after making any configuration changes in the MongoDB instance. If an incremental backup is scheduled to run after you make the configuration changes, then run a full backup manually before the incremental backup.
For examples, when you modify the MongoDB Feature Compatibility Version (FCV), MongoDB version, authentication type, topology (addition of new shards or removal of existing shards), storage parameters, etc. then run a full backup.