About SRGTechnical ArticlesRecruitment Information
About SRGTechnical ArticlesRecruitment Information
HOME/Technical 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) is a group that mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
This article is about Percona's MongoDB backup tool.We will explain about:
 

Introduction

When you think of Percona, you think of MySQL, 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 option that comes to mind. We use it because it offers many benefits in terms of automating server deployment management. However, the cost of using backups can be quite high and can be 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 Percona Backup for MongoDB to see how useful it 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 the storage for storing backups.
Essentially, the secondary in each replica set is the backup target, which has the benefit of separating and reducing the load during backup from production workloads.
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 version of MongoDB, so it looks like the only features available with the Community version will be logical backup + PITR.
The drawback of logical backup is that it tends to take a long time to complete, but it is still a very useful tool because it allows for online backup while maintaining consistency.
 

Try PBM on MongoDB Community

Setting up PBM

First, deploy a sharded cluster on k8s (minikube) (the most tedious step).
The mongod pod includes the pbm-agent as a sidecar.
We also use MinIO as a backup 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 backup of all replica sets is 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 restore verification.
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 and confirm that it has returned to 0.
 

Try Point-in-Time Recovery

The PITR scenario confirms that after adding 0 to 1000 data items, it can be restored to a specific time. Here, we consider it 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
 
Ensures that you can recover to a specific time.
 
You have now recovered to a specific time.
After completing the work, 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 of logical backup, and since we want to avoid running backups for long periods of time in a production environment, I felt it might be a bit difficult to adopt this in the current product.
However, I think it could be a very 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 they 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're interested, please contact us here.
 
SRG runs a podcast where we chat about the latest hot topics in IT technology and books. We hope you'll listen to it while you work.