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 OKstatus:
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 OKPITR 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 !!!
