Veritas NetBackup for MongoDB Administrator's Guide
- Overview of protecting MongoDB using NetBackup
- Installing and deploying MongoDB plug-in for NetBackup
- Deploying the MongoDB plug-in
- Operating system and platform compatibility
- Downloading the plug-in
- Installing the MongoDB plug-in and the required EEBs
- Prerequisites and the best practices for deploying the MongoDB plug-in
- Post installation procedures
- Verifying the installation of the MongoDB plug-in
- Configuring NetBackup for MongoDB
- About the MongoDB configuration tool
- Prerequisites for manually creating the mongodb.conf file
- Configuring backup options for MongoDB using the mongodb.conf file
- Obtaining the RSA key of the MongoDB nodes
- Adding MongoDB credentials in NetBackup
- Using a non-root user as a host user
- Managing backup hosts
- Backing up MongoDB using NetBackup
- Backing up MongoDB data
- Prerequisites for backing up a MongoDB cluster
- Configuring NetBackup policies for MongoDB plug-in
- Creating a BigData backup policy
- Creating BigData policy using the NetBackup Administration Console
- Using the Policy Configuration Wizard to create a BigData policy for MongoDB clusters
- Using the NetBackup Policies utility to create a BigData policy for MongoDB clusters
- Using NetBackup Command Line Interface (CLI) to create a BigData policy for MongoDB clusters
- Restoring or recovering MongoDB data using NetBackup
- Restoring MongoDB data
- Prerequisites for MongoDB restore and recovery
- About the restore scenarios for MongoDB database from the BAR interface
- Using the BAR interface to restore the MongoDB data on the same cluster
- Using the BAR interface to restore the MongoDB data on an alternate cluster
- About restoring MongoDB data in a high availability setup on an alternate client
- Recovering a MongoDB database using the command line
- Manual steps after the recovery process
- Troubleshooting
- Appendix A. Additional information
Using the BAR interface 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:
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
Rename the application server and its nodes and set the value for the alternate application server.
In the BAR UI select the tab > and use to add the alternate application server and port.
To change the folder path, select and add the new destination path.
Click Start Restore to start the recovery operation. You can check the status from the Activity Monitor.
You can restore the MongoDB oplog files from an incremental backup to an alternate path. The files and their path are seen in the BAR UI.
You must specify the paths during the alternate restore using the option.
If you want to retain the original MongoDB path but change the oplog file path, in the dialog box, specific the source and alternate paths.
For example, Source /host:port/tmp and Destination /host:port/alternate_tmp.
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
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