NetBackup™ for MongoDB Administrator's Guide

Last Published:
Product(s): NetBackup & Alta Data Protection (10.4)
  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 in the allowed list on the NetBackup primary server
    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.  
      Host user requirements
    7. Managing backup hosts
      1.  
        Including a NetBackup client on NetBackup primary server allowed list
  4. Backing up MongoDB using NetBackup
    1. About 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 for MongoDB clusters with web UI
  5. Restoring or recovering MongoDB data using NetBackup
    1.  
      About restoring MongoDB data
    2.  
      Prerequisites for MongoDB restore and recovery
    3.  
      Restore the MongoDB data on the same cluster
    4.  
      Restore the MongoDB data on an alternate cluster
    5.  
      Restoring MongoDB data in a high availability setup to an alternate client
    6.  
      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

Prerequisites for MongoDB restore and recovery

Review the following prerequisites and limitations before you begin the restore or the recovery process:

  • Ensure that your source MongoDB cluster and the target MongoDB cluster have the same:

    • MongoDB version

    • Authentication type

  • If the target MongoDB cluster runs under the mongod account, you need a non-root sudoer account. Also configure it as a host user in tpconfig before you start the restore. NetBackup recovers and runs the instance under the target cluster's user.

  • (Restoring MongoDB data to an alternate cluster) Ensure that you add the alternate MongoDB cluster credentials in the source cluster credentials file.

    See Adding MongoDB credentials in NetBackup.

  • Ensure that the PEM files or security certificates are available on the destination cluster before you start the recovery operation.

  • The authentication type of the target cluster during the recovery process must be the same as the authentication type during the backup.

  • Ensure that the target MongoDB cluster has sufficient free storage space for restoring the data.

  • Select only one full backup image group and its appropriate incremental images. If you select more than one full backup image group, the recovery may fail as the restored data can get corrupted.

  • NetBackup for MongoDB plug-in does not support cross-platform file system restore. For example, XFS to ext4 or vice versa is not supported.

  • Ensure that the HostUser value that is defined in the tpconfig command is the same as the host user account that is used to configure the MongoDB cluster. (MongoDB daemon's host user account.)

  • For the destination client, select a backup host before you submit the restore job.

  • Point-in-time recovery is valid only for recovery from incremental backups.

  • Canceling a parent job in a compound restore job does not cancel the child restore jobs. You must manually cancel the child restore jobs as well.

  • In a Restore Only operation for a sharded cluster, follow the standard Restore Only steps:

    Shut down all the MongoDB processes (mongos or mongod) before starting the restore.

    The tpconfig host user must have permission to the target folder in the original restore and alternate restore.

  • The MongoDB log file paths remain the same from the original configuration. If you do an alternate restore:

    • Make sure that the same path is available during restore.

    • Change the log file path in the configuration file for mongod or mongos process after a successful recovery.

  • The path to the .pid files must be available on the destination MongoDB cluster to ensure that the recovery operation is successful.

  • Special consideration is needed when you back up multiple MongoDB clusters that run on the same server. (Backups that use the same or different backup policies.) Ensure that you select the correct application server that you want to restore.

    For example, if there are multiple clusters with the following configuration: 

    Replica1
Primary: 		host1:26050
Secondary: host1:26060

Replica2
Primary: 		host1:26055
Secondary: host1:26066

    And you want to recover Replica1, ensure that you specify the correct application server and its port (host1-26050) as the Source client.

  • Before you start a recovery operation, ensure that stale mdbserver (thin client) processes are not running on your MongoDB instance at the following path:

    /<mdbserver_location>/<Host>-<MongodPort>-<mdbserver_port in range>/mdbserver

    If any of these stale processes are running, the recovery operation is unable to shut down the MongoDB instance which causes the recovery job to stop responding.

  • Restore and recovery of the MongoDB cluster requires the same security mode that is used at the time of the backup. Ensure that the security mode is the same for the original cluster and the target cluster.

    For example, if SSL is used during the backup, then recovery is done using SSL and the target configuration is changed to SSL. Similarly, if TLS is used during the backup, then recovery is done using TLS and the target configuration is changed to TLS.

  • Restore and recovery of the MongoDB cluster requires the same value of the Feature Compatibility Version (FCV) that is used at the time of the backup. Ensure that FCV is the same for the original cluster and the target cluster.

    For example, if FCV is 4.2 during the backup, then restore uses FCV 4.2 and the target cluster has FCV 4.2 after the recovery process completes. Similarly, if FCV is 4.0 during the backup, then restore uses FCV 4.0 and the target cluster has FCV 4.0 after the recovery process completes.