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:

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.