Restore a Replica Set to a New Environment with Percona Backup for MongoDB

restore a backup MongoDBPercona Backup for MongoDB (PBM) is our open source tool for backing up MongoDB clusters. Initially, the tool was developed for restoring the backups in the same environment they are taken. In this post, I will show you how to restore a backup to a new environment instead.

Let’s assume you followed the instructions to install Percona Backup for MongoDB packages on your newly provisioned replica set, and you already have at least one full backup of the source stored in remote backup storage.

Create the Backup User

Note: I am using a 3-node replicaset running in Centos 7 for this example.

The first step is to create the backup role on the target cluster’s primary:

Now, let’s also create the backup user and give it the proper permissions:

Configure PBM Agent

The next step is configuring the credentials for pbm agent on each server. It is important to point each agent to its local node only (don’t use the replicaset uri here):

Now we can start the agent on all nodes of the new cluster:

We have to specify the location where backups are stored. This is saved inside MongoDB itself. The easiest way to load the configuration options at first is to create a YAML file and upload it. For example, given the following file:

Use the pbm config –file command to save (or update) the admin.pbmConfig collection, which all pbm-agents will refer to.

Sync the Backups and Perform the Restore

As you can see, PBM automatically starts scanning the remote destination for backup files. After a few moments, you should be able to list the existing backups:

Note: in the case of a sharded cluster, the above connection must be to the config server replica set.

You can also use the following command if you need to re-run the scan for any reason:

The last step is to fire off the restore:

We can check the progress by tailing the journal:

Conclusion

Percona Backup for MongoDB is a must-have tool for sharded environments, because of multi-shard consistency. This article shows how PBM can be used for disaster recovery; everything is simple and automatic.

A caveat here is that unless you want to go into the rabbit hole of manual metadata renaming, you should keep the same replica set names on both the source and target clusters.

If you would like to follow the development, report a bug, or have ideas for feature requests, make sure to check out the PBM project in the Percona issue tracker.

Share this post

Leave a Reply