Percona 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.
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:
|
1 |
db.getSiblingDB("admin").createRole({ "role": "pbmAnyAction",<br> "privileges": [<br> { "resource": { "anyResource": true },<br> "actions": [ "anyAction" ]<br> }<br> ],<br> "roles": []<br> });<br> |
Now, let’s also create the backup user and give it the proper permissions:
|
1 |
db.getSiblingDB("admin").createUser({user: "pbmuser",<br> "pwd": "secretpwd",<br> "roles" : [<br> { "db" : "admin", "role" : "readWrite", "collection": "" },<br> { "db" : "admin", "role" : "backup" },<br> { "db" : "admin", "role" : "clusterMonitor" },<br> { "db" : "admin", "role" : "restore" },<br> { "db" : "admin", "role" : "pbmAnyAction" }<br> ]<br> });<br> |
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):
|
1 |
tee /etc/sysconfig/pbm-agent <<EOF<br>PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27017"<br>EOF |
Now we can start the agent on all nodes of the new cluster:
|
1 |
systemctl start pbm-agent |
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:
|
1 |
tee /etc/pbm-agent-storage.conf <<EOF<br>type:s3<br>s3:<br> region: us-west-2<br> bucket: pbm-test-bucket-78967<br> credentials:<br> access-key-id: "your-access-key-id-here"<br> secret-access-key: "your-secret-key-here"<br>EOF |
Use the pbm config –file command to save (or update) the admin.pbmConfig collection, which all pbm-agents will refer to.
|
1 |
$ pbm config --file=/etc/pbm-agent-storage-local.conf <br>[Config set]<br>------<br>pitr:<br> enabled: false<br>storage:<br> type: filesystem<br> filesystem:<br> path: /backup<br><br>Backup list resync from the store has started<br> |
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:
|
1 |
$ pbm list --mongodb-uri mongodb://pbmuser:secretpwd@localhost:27017/?replicaSet=testRPL<br>Backup snapshots:<br> 2020-11-02T16:53:53Z<br>PITR <off>:<br> 2020-11-02T16:54:15 - 2020-11-05T11:43:26 |
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:
|
1 |
pbm config --force-resync |
The last step is to fire off the restore:
|
1 |
$ pbm restore 2020-11-02T16:53:53Z --mongodb-uri mongodb://pbmuser:secretpwd@localhost:27017/?replicaSet=testRPL<br>...Restore of the snapshot from '2020-11-02T16:53:53Z' has started |
We can check the progress by tailing the journal:
|
1 |
$ journalctl -u pbm-agent -f<br><br>Nov 05 13:00:31 mongo0 pbm-agent[10875]: 2020-11-05T13:00:31.000+0000 [INFO] got command restore [name: 2020-11-05T13:00:31.580485314Z, backup name: 2020-11-02T16:53:53Z] <ts: 1604581231><br>Nov 05 13:00:31 mongo0 pbm-agent[10875]: 2020-11-05T13:00:31.000+0000 [INFO] restore/2020-11-02T16:53:53Z: restore started<br>Nov 05 13:00:34 mongo0 pbm-agent[10875]: 2020-11-05T13:00:34.918+0000 preparing collections to restore from<br>Nov 05 13:00:35 mongo0 pbm-agent[10875]: 2020-11-05T13:00:35.011+0000 reading metadata for admin.pbmRUsers from archive on stdin<br>Nov 05 13:00:35 mongo0 pbm-agent[10875]: 2020-11-05T13:00:35.051+0000 restoring admin.pbmRUsers from archive on stdin<br>Nov 05 13:00:35 mongo0 pbm-agent[10875]: 2020-11-05T13:00:35.517+0000 restoring indexes for collection admin.pbmRUsers from metadata<br>Nov 05 13:00:35 mongo0 pbm-agent[10875]: 2020-11-05T13:00:35.548+0000 finished restoring admin.pbmRUsers (3 documents, 0 failures)<br>Nov 05 13:00:35 mongo0 pbm-agent[10875]: 2020-11-05T13:00:35.548+0000 reading metadata for admin.pbmRRoles from archive on stdin<br>Nov 05 13:00:35 mongo0 pbm-agent[10875]: 2020-11-05T13:00:35.558+0000 restoring admin.pbmRRoles from archive on stdin<br>Nov 05 13:00:36 mongo0 pbm-agent[10875]: 2020-11-05T13:00:36.011+0000 restoring indexes for collection admin.pbmRRoles from metadata<br>Nov 05 13:00:36 mongo0 pbm-agent[10875]: 2020-11-05T13:00:36.031+0000 finished restoring admin.pbmRRoles (2 documents, 0 failures)<br>Nov 05 13:00:36 mongo0 pbm-agent[10875]: 2020-11-05T13:00:36.050+0000 reading metadata for admin.test from archive on stdin<br>Nov 05 13:00:36 mongo0 pbm-agent[10875]: 2020-11-05T13:00:36.061+0000 restoring admin.test from archive on stdin<br>Nov 05 13:01:09 mongo0 pbm-agent[10875]: 2020-11-05T13:01:09.775+0000 no indexes to restore<br>Nov 05 13:01:09 mongo0 pbm-agent[10875]: 2020-11-05T13:01:09.776+0000 finished restoring admin.test (1000000 documents, 0 failures)<br>Nov 05 13:01:09 mongo0 pbm-agent[10875]: 2020-11-05T13:01:09.901+0000 reading metadata for admin.pbmLockOp from archive on stdin<br>Nov 05 13:01:09 mongo0 pbm-agent[10875]: 2020-11-05T13:01:09.993+0000 restoring admin.pbmLockOp from archive on stdin<br>Nov 05 13:01:11 mongo0 pbm-agent[10875]: 2020-11-05T13:01:11.379+0000 restoring indexes for collection admin.pbmLockOp from metadata<br>Nov 05 13:01:11 mongo0 pbm-agent[10875]: 2020-11-05T13:01:11.647+0000 finished restoring admin.pbmLockOp (0 documents, 0 failures)<br>Nov 05 13:01:11 mongo0 pbm-agent[10875]: 2020-11-05T13:01:11.751+0000 reading metadata for test.test from archive on stdin<br>Nov 05 13:01:11 mongo0 pbm-agent[10875]: 2020-11-05T13:01:11.784+0000 restoring test.test from archive on stdin<br>Nov 05 13:01:27 mongo0 pbm-agent[10875]: 2020-11-05T13:01:27.772+0000 no indexes to restore<br>Nov 05 13:01:27 mongo0 pbm-agent[10875]: 2020-11-05T13:01:27.776+0000 finished restoring test.test (533686 documents, 0 failures)<br>Nov 05 13:01:27 mongo0 pbm-agent[10875]: 2020-11-05T13:01:27.000+0000 [INFO] restore/2020-11-02T16:53:53Z: mongorestore finished<br>Nov 05 13:01:30 mongo0 pbm-agent[10875]: 2020-11-05T13:01:30.000+0000 [INFO] restore/2020-11-02T16:53:53Z: starting oplog replay<br>Nov 05 13:01:30 mongo0 pbm-agent[10875]: 2020-11-05T13:01:30.000+0000 [INFO] restore/2020-11-02T16:53:53Z: oplog replay finished on {0 0}<br>Nov 05 13:01:30 mongo0 pbm-agent[10875]: 2020-11-05T13:01:30.000+0000 [INFO] restore/2020-11-02T16:53:53Z: restoring users and roles<br>Nov 05 13:01:31 mongo0 pbm-agent[10875]: 2020-11-05T13:01:31.000+0000 [INFO] restore/2020-11-02T16:53:53Z: restore finished successfully |
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.
Resources
RELATED POSTS