> CommCell Console > Backup and Restore Agents > Big Data Apps > MongoDB > MongoDB Restore Operations

Performing an Automated MongoDB Out-of-Place Restore Operation

You can restore an entire MongoDB cluster to a different location (out of place).

After the data transfer is complete, the restore operation starts the MongoDB servers automatically on all the restored clients and applies the restored Oplog dumps until the specified point in time or the latest backup.

In environments that include arbiter nodes that have the Commvault software installed, the arbiter nodes are shut down during restores. You must start and add the arbiter nodes to the shard or a replica set manually.

Before You Begin

  • If you have oplog dump backups enabled on the destination cluster, disable them.

  • In sharded clusters, the number of shards in source and destination clusters must be same.

  • The destination servers must have the same or higher version of MongoDB than the source.

  • If the MongoDB server config file is located in the dbPath directory, then make a copy of the configuration file.

  • During recovery, the MongoDB log file is created in the /var/log/mongodb directory if the directory exists. Otherwise, the MongoDB log file is created in the /var/log directory. Verify that the operating system user has permissions on this directory to create the log file.

  • In Linux environments, verify that the user ID and group ID of the OS user that is used for starting the MongoDB server is the same on the source and destination clusters across all nodes.

  • Ensure that the MongoDB credentials of the source cluster are updated in the instance properties of the destination cluster so that the restore operation completes successfully. This action is required only if destination cluster has client authentication enabled.

  • To restore the Oplog dumps, the MongoDB authentication user account associated with the cluster must have the following role in the admin database: db.grantRolesToUser("$[user_name]", [{ role: "anyActionAnyResource", db: "$[admin]" }]).

Procedure

  1. From the CommCell Browser, expand Client Computers > client > Big Data Apps > instance.

  2. Right-click the subclient, and then click Browse and Restore.

    The Browse and Restore Options dialog box appears.

  3. Specify the restore operation that you want to perform:

    • To restore the most recent backup, select Latest Backup.

    • To restore the data to a point-in-time, select Time Range, and then in the Start and End boxes, type the date and time.

      The end time must be later than the very next backup job that ran after the point-in-time you select.

      Example of point-in-time restore

      Consider the following job information for backup operations:

      Backup type

      Job start time

      Job end time

      Full

      10:00 am

      10:15 am

      Incremental backup 1

      10:30 am

      10:35 am

      incremental backup 2

      11:00 am

      11:05 am

      Incremental backup 3

      11:30 am

      11:35 am

      Now, suppose that you want to perform a restore operation to a point in time at 10:45 am, enter the end time as 11:06 am because the most recent job succeeded at 11:05 am, which is after the point-in-time that you selected.

  4. Click View Content.

  5. On the Browse page, determine the data that you want to restore, and then click Recover All Selected.

    The Restore Options dialog box appears.

  6. On the General tab, select the restore options:

    1. From the Destination instance list, select a client computer and an instance.

      The client computer is a different client from the source client computer.

    2. To restore the files only, select the Restore files only check box.

      If you select this option, the user must start the servers manually and initiate the replica sets. See Performing a Manual MongoDB Restore Operation for a Sharded Cluster or Performing a Manual MongoDB Restore Operation for a Replica Set.

    3. To shut down the destination server and to clean up the dbPath directory before the restore operation, select the Automatic Restore check box.

      Note

      If the Automatic Restore check box is disabled, then you must shut down the servers manually and clean up the dbPath before submitting the restore operation. In addition, on Linux, if there are any symbolic links to dbPath or under dbPath, they must not be removed.

    4. In the Number of Streams box, type the number of streams that the software uses for the restore operation.

    5. For each shard or replica set, enter the destination client, dbPath, and port number.

  7. Optional: Select the advanced restore options. For more information, review the following:

  8. On the Recover tab, select the Recover and Apply Oplog Until check box.

    Note

    If the Oplog dump restore fails with the error 'oplog: applyOps: (Unauthorized) not authorized on admin to execute command', even though the MongoDB authentication user account has both the restore and clusterAdmin roles assigned, you can temporarily assign the following role to the user account to perform the restore operation. This role can be revoked once the restore completes.

    db.grantRolesToUser("$[user_name]", [{ role: "anyActionAnyResource", db: "$[admin]" }])

  9. Specify the recover operation that you want to perform:

    • To recover from the most recent backup, select Latest Backup Time.

    • To recover the database to a point-in time, click Point-in-time, and then select the data and time to which you want to recover the database.

  10. Click OK.

What to Do Next

To add additional secondary nodes (if any) to the replication set, do the following:

  1. Connect a mongo shell to the restored mongod instance,and then run the following command:

    rs.add("hostname:port")

    This command will synchronize the member with the data on the primary node.

  2. For sharded clusters, start the mongo routing service (mongos) on the required nodes:

    mongos --config <path-to-config>

  3. On the primary, to re-configure any node information such as priority votes and so on, use rs.reconfig().

    For example, to configure the priorities of nodes after a restore operation, connect to the primary node's mongo shell and run the following commands.

    Note

    Wait till the secondaries change to the secondary state.

    cfg = rs.conf();
cfg.members[2].priority = 1;
rs.reconfig(cfg);
cfg = rs.conf();
cfg.members[3].priority = 1;
rs.reconfig(cfg);
cfg = rs.conf();
cfg.members[4].priority = 1;
rs.reconfig(cfg);

  4. After the restore operation is complete, MongoDB server is started as a process using the config file that the Commvault software has created during the restore process. To start the MongoDB server using another config file, stop the MongoDB server after completing the restore operation, and restart the MongoDB server.

×

Loading...