NetBackup™ for MongoDB Administrator's Guide

Last Published:
Product(s): NetBackup & Alta Data Protection (10.3.0.1, 10.3)
  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 primary 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 primary 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 for MongoDB clusters with web UI
  5. Restoring or recovering MongoDB data using NetBackup
    1.  
      Restoring MongoDB data
    2.  
      Prerequisites for MongoDB restore and recovery
    3.  
      Using NetBackup web UI to restore the MongoDB data on the same cluster
    4.  
      Using NetBackup web UI to restore the MongoDB data on an alternate cluster
    5.  
      About restoring MongoDB data in a high availability setup on 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
  8.  
    Index

Using NetBackup web UI to restore the MongoDB data on an alternate cluster

NetBackup supports the following alternate recovery scenarios for MongoDB:

  • Redirected restore and recovery to an alternate cluster

  • Redirected restore and recovery to an alternate node or port or database path in an existing cluster

Complete the following steps to run alternate recovery for MongoDB:

  1. Run the tpconfig command to update the original cluster's credentials with the alternate application server's credentials.

    For example, to recover source client Host1-26050 to an alternate application server Host2 that is running on port 28001:

    • Add the credentials of Host2:28001 and its related nodes in the original cluster's credential configuration file. For more information, See About the credential configuration file.

    • Run the update tpconfig command for application_server that is getting recovered (Host1-26050)

    Here is a sample command:

    /usr/openv/volmgr/bin/tpconfig -update -application_server Host1-26050 -application_type mongodb -requiredport 26050 -application_server_conf /usr/openv/var/global/credential.conf

  2. Rename the application server and its nodes and set the value for the alternate application server.

    On the NetBackup web UI:

    • On the left, select Recovery.

    • On the Recoverpage, Regular recovery wind, click Start recovery.

    • On the Basic properties tab, enter the following:

      • Select the Policy type as BigData > MongoDB

      • Specify the MongoDB application server as the source for which you want to perform the restore operation.

      • From the Source client list, select the required Application server.

      • Specify the backup host as the destination client.

      • From the Destination client list, select the required backup host. Restore is faster if the backup host is the media server that had backed up the node.

      • Click Next.

    • On the Recovery details tab, do the following:

      • Select the appropriate date range to restore the complete data set or go to Use backup history and select the backup images that you want to restore.

      • From left directory hierarchy, select the files and folders for restore.

        Note:

        All the subsequent files and folders under the directory are displayed in the right pane.

      • Click Next.

    • On the Recovery options tab, do the following:

      • Select Restore individual directories and files to different locations to restore your files to the same location where you performed your backup.

      • In MongoDB options, select Restore and recover and recover databases for current time or select the specific schedule.

      • Click Next.

    • Review and click Start recovery.

    • To change the folder path, select Add Destination and add the new destination path.

    See Alternate restore from a nested database path.

  3. Click Start Restore to start the recovery operation. You can check the status from the Activity Monitor.

Restoring the MongoDB oplog file to an alternate temporary location

You can restore the MongoDB oplog files from an incremental backup to an alternate path. The files and their path are seen in the web UI.

You must specify the paths during the alternate restore using the Restore individual directories and files to different locations option.

If you want to retain the original MongoDB path but change the oplog file path, in the Add Destination dialog box, specific the source and alternate paths.

For example, Source /host:port/tmp and Destination /host:port/alternate_tmp.

Alternate restore from a nested database path

For an alternate restore from a nested database path, use the Add Destination dialog box and for every subfolder, add an appropriate target alternate path.

For example, to change the path from /host:port/usr/mongodb/db1 to /host:port/alt-dir/dbpath/mydb:

  • Specify the source and the destination path:

    Source /host:port/usr/mongodb/db1 and Destination /host:port/alt-dir/dbpath/mydb

  • Specify the source and the destination path for the parent folder:

    Source /host:port/usr/mongodb and Destination /host:port/alt-dir/dbpath

  • Specify the source and the destination path for the base parent folder:

    Source /host:port/usr and Destination /host:port/alt-dir

    Note:

    When you do an alternate restore to a non-root path, the restore is partially successful if the database path contains multiple subfolders.

    In such a scenario, when you do an alternate restore to a different location, you must add an entry for each directory level.

    For example:

    Source:/hostname1:port1/Config_Data

    Destination: /hostname2:port3/mongo_inst2

    Source:/hostname1:port1/Config_Data/data

    Destination:/hostname2:port3/mongo_inst2/data

    Source:/hostname2:port2/Shard1_Primary

    Destination:/hostname2:port3/mongo_inst2

    Source:/hostname2:port2/Shard1_Primary/data

    Destination:/hostname2:port3/mongo_inst2/data

Restoring a MongoDB cluster where the backups are taken from different MongoDB nodes in the same replica set

You can restore a MongoDB cluster (sharded or replica set) that was backed up from different nodes because of the role switch (between primary and secondary nodes) within a shard or replica set. In such a scenario, the full backup can be taken from one host and incremental backup is taken from another host in the same shard or replica set.

During restore, you must redirect the restore of these backup images to the same MongoDB host.

For example, to restore backups from /host1:port1/dbpath and /host2:port1/tmp, specify the following:

Source /host1:port1/dbpath and Destination /althost:port1/dbpath

Source /host2:port1/tmp and Destination /althost:port1/tmp