Veritas NetBackup™ for MongoDB Administrator's Guide

Last Published:
Product(s): NetBackup (9.1)
  1. Overview of protecting MongoDB using NetBackup
    1.  
      About protecting a sharded, replica set, or standalone MongoDB cluster using NetBackup
    2.  
      Protecting MongoDB data using NetBackup
    3.  
      NetBackup for MongoDB terminologies
    4.  
      Limitations
    5.  
      Prerequisites and the best practices for protecting MongoDB
  2. Verify the pre-requisites for the MongoDB plug-in for NetBackup
    1.  
      Operating system and platform compatibility
    2.  
      Prerequisites for configuring the MongoDB plug-in
  3. Configuring NetBackup for MongoDB
    1.  
      About the MongoDB configuration tool
    2.  
      Prerequisites for manually creating the mongodb.conf file
    3. Configuring backup options for MongoDB using the mongodb.conf file
      1.  
        Including the configuration file path on NetBackup master server allowed list
    4.  
      Obtaining the RSA key of the MongoDB nodes
    5. Adding MongoDB credentials in NetBackup
      1.  
        About the credential configuration file
      2.  
        How to add the MongoDB credentials in NetBackup
      3.  
        About the MongoDB roles for protecting the data
    6.  
      Using a non-root user as a host user
    7. Managing backup hosts
      1.  
        Including a NetBackup client on NetBackup master server allowed list
  4. Backing up MongoDB using NetBackup
    1. Backing up MongoDB data
      1.  
        Backing up a MongoDB cluster
    2.  
      Prerequisites for backing up a MongoDB cluster
    3. Configuring NetBackup policies for MongoDB plug-in
      1.  
        Creating a BigData backup policy
      2.  
        Creating BigData policy using the NetBackup Administration Console
      3.  
        Using the Policy Configuration Wizard to create a BigData policy for MongoDB clusters
      4.  
        Using the NetBackup Policies utility to create a BigData policy for MongoDB clusters
      5.  
        Using NetBackup Command Line Interface (CLI) to create a BigData policy for MongoDB clusters
  5. Restoring or recovering MongoDB data using NetBackup
    1.  
      Restoring MongoDB data
    2.  
      Prerequisites for MongoDB restore and recovery
    3. About the restore scenarios for MongoDB database from the BAR interface
      1.  
        High-level steps involved in the Restore and Recovery process
    4.  
      Using the BAR interface to restore the MongoDB data on the same cluster
    5.  
      Using the BAR interface to restore the MongoDB data on an alternate cluster
    6.  
      About restoring MongoDB data in a high availability setup on an alternate client
    7. Recovering a MongoDB database using the command line
      1.  
        Creating or modifying the rename file
      2.  
        Using the command line to recover a MongoDB database
    8.  
      Manual steps after the recovery process
  6. Troubleshooting
    1.  
      About NetBackup for MongoDB debug logging
    2.  
      Known limitations for MongoDB protection using NetBackup
  7. Appendix A. Additional information
    1.  
      Sample MongodB configuration utility workflow to add and update MongodB credentials
  8.  
    Index

Prerequisites and the best practices for protecting MongoDB

Prerequisites
  • 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 MongoDB clusters and backup hosts.

  • The NetBackup for MongoDB plug-in requires that the NetBackup master 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 and SUSE 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 .tar files 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_config file.

    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 master 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 master and media server. Backup host versions earlier than 9.0 can affect the MongoDB 4.2 cluster.

Best practices for communication between MongoDB and NetBackup
  • If you use a NetBackup client as a backup host, ensure to add the following value in the bp.conf file of the NetBackup master server:

    APP_PROXY_SERVER=NBU_CLIENT_FQDN

  • If 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 the sudoers file in the operating system.

  • If you install the MongoDB using the .tar file or to a non-default location, add the path of the MongoDB bin folder in the bashrc file 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.conf HostPassword, 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 the mongodb.conf file, 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

Best practices for protecting MongoDB using NetBackup
  • 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.conf file. 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.conf file before you run a backup or restore job.

  • Ensure that the path of the security certificates that are added in the mongod.conf file 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.conf or the mongos.conf file to start the MongoDB processes, run the mongod file 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.