When you design a backup strategy, you need to think about the business requirements, as you will need to shape your backups to meet them. Let’s review the basics briefly; you need to define the RPO and RTO. The RPO stands for “Recovery Point Objective”, which means how far back you will be able to recover. The RTO stands for “Recovery Time Objective”, this is the time the business expects the data to be recovered. This article will focus on one scenario that can help to meet the RTO.

The scenario

Imagine the company has a replica set running Percona Server for MongoDB 6.0 (PSMDB). This replica set has a footprint of one terabyte. The operations team has also configured Percona Backup for MongoDB (PBM) to generate physical and logical backups. One terrible day, a chain of unfortunate events occurs; one developer gets a call from his manager about a critical bug found on the PRODUCTION system, he quickly goes through the code that was released yesterday and finds that the issue can be easily fixed by removing a set of documents inserted on a collection. As he has read-write access to the PRODUCTION database, he decided to be fast and run the delete command directly on PRODUCTION to try to mitigate the issue as fast as possible. As you can imagine, when someone does things fast, the tendency to make a mistake is high. This was the case, and 90% of the documents in this collection were removed, and now the problem is even bigger than a critical bug — the system is completely down.

The solution

Since the database is rather large, it can take a long time to restore the whole thing, and given that a single collection is the culprit, it will be faster to execute a restore for that single collection.

The first thing to do is to list the backups available:

Next, we need to find the most recent logical backup, as the restore of selected collections requires a logical backup. In this case, the backup that we need is “2024-03-22T20:42:50Z”.

Now, we have two options: 

  1. Restore the collection on the live database: This will overwrite the existing data in the collection. If you are sure that no additional data was added to the collection, then this definitely is the fastest and simplest path.
  2. Restore the collection on a temporary instance: This will allow you to export and import the data into the live database without overwriting the new data generated. This alternative adds more steps to the process, but we can preserve the existing data.

Option one

Restore the single collection into the live database:

You can view what is  PBM doing by running the following command:

In this case, the restore process is complete; you can list the restore operations with the following command:

You can see the restore details with this command:

Finally, confirm the data was restored as expected

Option two

Create a mongod config file for the temporary instance:

Create the dbPath:

Start the temporary instance:

Configure PBM to run on the new instance and make sure it has point-in-time recovery (PITR) disabled. In this case, the new instance is running on port 27018.

Force a sync to pull the list of backups stored on the S3 bucket:

List the backups and make sure the logical backup you require is present:

Restore the collection you need to recover:

Export all the documents from the recovered collection:

Import the archive file into the live database, this will append the data.

Alternate solution

If the requirement is to recover the data up until the second when it was deleted, then we should do a PITR. For this option to be viable, we need to have this feature enabled in PBM. Due to the size of the database, we will need a separate server to execute the restore process. The steps to perform this are detailed on this documentation page, Make a point-in-time restore. Once you have the database restored up to the time you need it, you can export the collection documents and import them as we did on the second option.

Percona Backup for MongoDB flexibility

The flexibility that PBM offers to manage the backup and restore operations is unique, and this is just a simple scenario that PBM can help you with. It is important to understand how PBM works to be able to build strategies to meet the business needs. If you need help managing your databases, don’t hesitate to contact us, we have an excellent team of experts ready to help.

Percona Distribution for MongoDB is a source-available alternative for enterprise MongoDB. A bundling of Percona Server for MongoDB and Percona Backup for MongoDB, Percona Distribution for MongoDB combines the best and most critical enterprise components from the open source community into a single feature-rich and freely available solution.

 

Download Percona Distribution for MongoDB Today!

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments