About SRGArticlesRecruitment Information
About SRGArticlesRecruitment Information
HOME/Articles/Try Percona Backup for MongoDB

Try Percona Backup for MongoDB

This is Ohara (@No_oLimits) from the Service Reliability Group (SRG) of the Technology Headquarters.
#SRG(Service Reliability Group) mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, contributing to OSS, etc.
This article is about Percona's MongoDB backup tool.We will explain about:
 

Introduction

Percona is known for its MySQL database, but thankfully they also provide useful information about MongoDB.
In addition to MySQL, we also use MongoDB as a data store for several of our products.
When considering MongoDB backup operations (as well as deployment management and monitoring), Atlas / Cloud Manager is the first candidate that comes to mind, and we use it because it has many benefits in terms of automating server deployment management. However, the cost of using backups can be quite high and become a burden, so in such cases we do not use the backup function and instead take backups using a different method (disk snapshots).
So I would like to investigate and try out how useful Percona Backup for MongoDB is.
 

About Percona Backup for MongoDB (PBM)

https://docs.percona.com/percona-backup-mongodb/index.html
This is an architecture diagram of PBM.
 
pbm-agent
Configuration related to backup management is stored in the config server, and it is assumed that AWS S3 or similar will be used as storage for storing backups.
Essentially, the secondary in each replica set is the backup target, which has the benefit of isolating and reducing the load during backup from the production workload.
In addition, the backup function in the monitoring product PMM (Percona Monitoring and Management) appears to use PBM internally.
 

What can PBM do?

https://docs.percona.com/percona-backup-mongodb/features/backup-types.html
There seems to be a difference in the backup types available in MongoDB Community and Percona Server for MongoDB.
This time I was planning to test it with the Community edition of MongoDB, so it looks like the only features available in the Community edition will be logical backup + PITR.
The drawback of logical backups is that they tend to take a long time to complete, but they are still a very useful tool because they allow online backups while maintaining consistency.
 

Try PBM on MongoDB Community

Setting up PBM

First, deploy a sharded cluster on k8s (minikube) (the most tedious task).
The pbm-agent resides in the mongod pod as a sidecar.
We also use MinIO as a backup storage destination.
I won't go into that here, but I'll assume that you've already configured the replica set and added shards.
 
PBM_MONGODB_URI
 
Next we will configure the backup storage. We will do this in the pbm-agent container.
Please prepare appropriate access keys and buckets for MinIO in advance.
 
Start the pbm-agent on each mongod server.
pbm status
 

Backup-related operations

As a mechanism for maintaining the consistency of the full backup (logical), it appears that each replica set captures the oplog until the backups of all replica sets are complete.
Therefore, the target for restore will be the time when the backup was completed.
The main commands of PBM CLI are as follows. Backup operations are very easy, simple and straightforward.
 

Try a full backup and restore

Proceed to verify the restore.
test.data
 
A backup will be taken when there are 0 items.
 
Add data.
 
There are a few things to check before restoring.
https://docs.percona.com/percona-backup-mongodb/usage/restore.html
The main points to note about PBM are as follows:
  • Disable PITR before restoring.
  • The collection that existed at the time of backup is the target for restoration.
    • Any new collections created after the backup will not be deleted when restoring (so delete the collections if you want to make the data consistent).
Additionally, when restoring a shard cluster, it is still necessary to stop the balancer and any unnecessary updates from mongos.
 
Restore it. Check that it has returned to 0.
 

Try Point-in-Time Recovery

The PITR scenario is to confirm that after adding 0 to 1000 data items, it can be restored to a specific time. Here, it is OK if the number of items is roughly between 0 and 1000 after recovery.
First, enable PITR and take a base backup.
 
Data will be added in stages from 0 to 1000 items.
If updates occur to the database after a full backup, you can see that recovery points for PITR are being recorded.
2023-11-28T11:20:53Z
 
Ensure that you can recover to a specific time.
 
You have now recovered to a specific time.
Once you are done, enable PITR again and take a base backup.
 

Conclusion

Let's take a look at the features of PBM.
The Community version only has the option for logical backup, and since we want to avoid running long backups in a production environment as much as possible, I felt it might be a bit difficult to adopt this in the current product.
However, I think it could be a useful tool depending on the requirements for backup operations.
Even if we use Percona Server for MongoDB to enable physical backups, there are concerns that it will no longer be managed by Cloud Manager, so I would like to see more features available in the Community version.
 
SRG is looking for people to work with us. If you are interested, please contact us here.
 
SRG runs a podcast where we chat about the latest hot topics in IT and books. We hope you will enjoy listening to it while you work.