Veritas NetBackup™ for MongoDB Administrator's Guide

Last Published:
Product(s): NetBackup (9.0.0.1, 9.0)
  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.  
        Whitelisting the configuration file path on NetBackup master 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.  
      Using a non-root user as a host user
    7. Managing backup hosts
      1.  
        Whitelisting a NetBackup client on NetBackup master server
  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 for MongoDB restore and recovery

  • Ensure that your source MongoDB cluster (during backup) and the target MongoDB cluster (during recovery) have the same:

    • MongoDB version

    • Authentication type

  • Ensure that the user that you configure using the tpconfig command for restoring the MongoDB data has read, write, and execute permissions for all the files and subfolders on the target MongoDB directory. NetBackup uses this user account to recover and run the MongoDB instance.

  • Before you restore the 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.

  • During the recovery process, ensure that the target MongoDB cluster has sufficient free storage space for restoring the data.

  • During recovery, ensure that you select only one full backup image group and its relevant subsequent 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.

  • During the restore or recovery, 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).

  • Ensure to select a backup host in destination client in the BAR UI 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.

  • After running a restore or a recovery job from the BAR interface, look for the job record and status in the Task Progress tab. The job might take some time to appear in the list and the compound job can take time to trigger the parent pre-recovery check. Click Update Task List to refresh the task list.

  • 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 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.

  • In case of a scenario where multiple MongoDB clusters are running on the same server and are backed up using 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 correct application server and its port (host1-26050) as the source client in the BAR UI.

  • 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 stale mdbserver processes are running on the MongoDB host for the same MongoDB instance that you want to recover, the recovery operation is unable to shutdown the MongoDB instance. This issue 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 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.