Restore and Point in time Restore with Percona Backup of MongoDB on another instance

In the previous percona blog we have seen deploy percona mongodb and percona backup for mongodb

In this we are going to recover the data into new server in easy method

Even if we have multiple solutions sometimes we cant restore the data before seconds , its takes more time for point in time restore or its needs more efforts

But Percona Backup for MongoDB ( PBM Backup ) is easiest method to backup to aws , azure or NFS Drives also easy to attach any new servers we deploy in case of old system failures

Environment :

We have configured two mongo servers ( one is primary and another one is secondary )

In this case regular basis we are taking PBM full backup as well incremental backup every 2 minutes interval

Problem :

We had a problem with disk and all the data was collapsed unable to recover data as immediately

Its all critical data , we have to recover as much as possible

Recovery of Mongo Servers :

God grace in the same region we had two mongo servers stopped state and configured with replication

We have immediately startup the servers and managed to bring up mongo instance as well as replication

So now we have to recover the data , as of now 8 minutes taken to complete all these

Rebuild of PBM Backup :

As we explained previous blog , completed the PBM backup configuration as same like corrupted server and we are able to see the last 2 minutes incremental as well as full backup

Repository : sudo percona-release enable pbm release

Update : sudo apt update

Install : sudo apt install percona-backup-mongodb

Startup : sudo systemctl start pbm-agent , sudo systemctl enable pbm-agent

Users and Privileges :

db.getSiblingDB(“admin”).createRole(

{ “role”: “pbmAnyServerAction”,

“privileges”: [

{ “resource”: { “anyResource”: true },

“actions”: [ “anyAction” ]}],”roles”: []});

— — — — —

db.getSiblingDB(“admin”).createUser({user: “pbmadmin”,

“pwd”: “xxxxxxxxxxx”,

“roles” : [

{ “db” : “admin”, “role” : “readWrite”, “collection”: “” },

{ “db” : “admin”, “role” : “backup” },

{ “db” : “admin”, “role” : “clusterMonitor” },

{ “db” : “admin”, “role” : “restore” },

{ “db” : “admin”, “role” : “pbmAnyServerAction” }]});

— — — — —

pbm_config.yaml

account , container , key and prefix should be same as corrupted system PBM configuration

backup:
priority:
“10.10.x.x:27017”: 1.0
“10.10.x.x:27017”: 0.5
pitr:
enabled: true
oplogSpanMin: 2
storage:
type: azure
azure:
account: xxxxxxxx
container: xxxxx
prefix: xxxxxx
credentials:
key: xxxxxxxx
#storage:
# type: filesystem
# filesystem:
# path: /mongodata/pbmbackup
restore:
batchSize: 500
numInsertionWorkers: 10

Add Environment Variable

vi ~/.bashrc

export PBM_MONGODB_URI=”mongodb://pbmadmin:xxxxxx@xxxxx:27017/?authSource=admin&replicaSet=xxxxxx”

source ~/.bashrc

Add agent

vi /etc/default/pbm-agent

PBM_MONGODB_URI=”mongodb://pbmadmin:xxxxx@xxxx:27017/?authSource=admin&replicaSet=xxxxx”

sudo systemctl restart pbm-agent

All done now just config the pbm configuration

root@DRDB01:/mnt/pbm# pbm config — file /mongodata/pbm/pbm_config.yaml
pitr:
enabled: true
oplogSpanMin: 2
compression: s2
storage:
type: azure
azure:
account: xxxxxx
container: xxxxx
prefix: xxxxx
credentials:
key: ‘***’
restore:
batchSize: 500
numInsertionWorkers: 10
backup:
priority:
10.10.x.x:27017: 0.5
10.10.x.x:27017: 1
root@DRDB01:/mnt/pbm#

Once we have done the quick steps in both primary and secondary we have configured PBM backup in less then 3 minutes

Now we can check status of PBM Backup

root@DRDB01:/mnt/pbm# pbm status
Cluster:
========
prod-replication :
— prod-replication/DRDB01:27017 [P]: pbm-agent v2.0.3 OK
— prod-replication/DRDB02:27017 [S]: pbm-agent v2.0.3 OK

status:

PITR incremental backup:
========================
Status [ON]

Currently running:
==================
(none)

Backups:
========
Azure https://xxxxxx.blob.core.windows.net/xxxx/xxxxxx
Snapshots:
2023–02–15T07:02:47Z 31.43MB <logical> [restore_to_time: 2023–02–15T07:04:07Z]
PITR chunks [51.00KB]:
2023–02–15T07:04:08Z — 2023–02–15T07:32:12Z

as highlighted on above we have full backup also incremental backup to restore the data .

Recovery :

Before restoring the data we have to disable pitr variable in config file and start restore

root@DRDB01:/mnt/pbm# pbm status
Cluster:
========
prod-replication :
— prod-replication/DRDB01:27017 [P]: pbm-agent v2.0.3 OK
— prod-replication/DRDB02:27017 [S]: pbm-agent v2.0.3 OK

PITR incremental backup:
========================
Status [OFF]

Currently running:
==================
(none)

Backups:
========
Azure https://xxxxxx.blob.core.windows.net/xxxx/xxxxxx
Snapshots:
2023–02–15T07:02:47Z 31.43MB <logical> [restore_to_time: 2023–02–15T07:04:07Z]
PITR chunks [51.00KB]:
2023–02–15T07:04:08Z — 2023–02–15T07:32:12Z

Lets restore the data backup now ,

root@DRDB01:/mnt/pbm# pbm restore 2023–02–15T07:02:47Z
Starting restore 2023–02–15T17:22:11.143118226Z from ‘2023–02–15T07:02:47Z’…Restore of the snapshot from ‘2023–02–15T07:02:47Z’ has started

Excellent now all the data has been restored ,

prod-replication [direct: primary] test> show dbs;
xxxxx 40.00 KiB
xxxx 1.00 MiB
xxxx 232.00 KiB
xxx-xxx 48.00 KiB
xxxxxx-01dba99b-ab6e-44f9-aa8b-1f6ffd945820 48.00 KiB
xxxxx-064c6773-b4d1–4d67–925d-df41af02101d 8.00 KiB
xxxx-08c0ef86–7eb8–4608-ae33–21e05f915149 88.00 KiB
xxxxx-1478a4fe-6551–4376–832a-75f0f19dd633 100.00 KiB

Point in time Restore :

PITR chunks [51.00KB]:
2023–02–15T07:04:08Z — 2023–02–15T07:32:12Z

Have choosed 07:15 time data for point in time restore ,

root@DRDB01:/mnt/pbm# pbm restore — time=”2023–02–15T07:15:08"
Starting restore to the point in time ‘2023–02–15T07:15:08’…Restore to the point in time ‘2023–02–15T07:15:08’ has started
root@DRDB01:/mnt/pbm#

Its very less cost effective method to backup and recover the data . We have easily recovered the data within 15 minutes of time

Have a happy data recovery !!!