Skip to content

Create MongoDB PITR backups

Point-in-Time Recovery (PITR) restores databases up to a specific moment in time. PITR includes restoring the data from a backup snapshot and replaying all events that occurred to this data up to a specified moment from oplog slices.

Point-in-Time Recovery helps you prevent data loss during a disaster such as crashed database, accidental data deletion or drop of tables, or unwanted update of multiple fields instead of a single one.

Compatibility with Percona Backup for MongoDB

PMM introduced the option to create PITR Backups for MongoDB in version 2.23, as part of the larger Backup Management feature. This implementation in PMM uses Percona Backup for MongoDB (pbm) behind the scenes.

Percona Backup for MongoDB is a distributed, low-impact solution for achieving consistent backups of MongoDB sharded clusters and replica sets. Starting with PMM 2.32, restoring PITR backups is available for backups based on pbm ≤ 2.0.1. To restore PITR backups, make sure you have pbm ≥ 2.0.1 installed.

Percona Backup for MongoDB supports Percona Server for MongoDB and MongoDB Community ≤ 3.6, with MongoDB Replication enabled. For more information, see the Percona Backup for MongoDB documentation.

How does it work?

When point-in-time recovery (PITR) is enabled, pbm-agent periodically saves consecutive slices of the oplog.

To start saving oplog, PBM requires a backup snapshot. Such snapshots are being created when you activate a PITR scheduled task in PMM.

Since PBM saves oplog slices and streams them into your storage between scheduled task runs, scheduling frequent PITR backups is not necessary. You can use the available oplog slices in your storage to restore a backup to any moment between snapshots.

Before creating a backup, make sure to check the MongoDB backup prerequisites.

  1. Go to Backup > All Backups.
  2. Click Create Backup.
  3. Select the Schedule Backup option in the Create Scheduled backup window.
  4. Enter a unique name for this backup.
  5. Choose the service to back up from the Service name drop-down menu. This automatically populates the DB Technology field.
  6. Select Logical as this is the only data model that currently supports PITR backups.
  7. Choose a storage location for the backup. MongoDB supports both Amazon S3-compatible and local storage. However, restoring from local storage is not supported yet. If no options are available here, see the Create a storage location topic.
  8. Specify the backup type and the schedule for your backup:
    • Backup Type: select the PITR option.
    • Schedule: configure the frequency and the start time for this backup.

    Important

    Make sure that the schedule you specify here does not create overlapping jobs or overhead on the production environment. Also check that your specified schedule does not overlap with production hours.

    • Retention: this option is not available for PITR backups. Currently, retention policies can only be specified for Snapshot backups stored on Amazon S3-compatible storage.
  9. Expand Advanced Settings to specify the settings for retrying the backup in case of any issues. You can either let PMM retry the backup again (Auto), or do it again yourself (Manual).
    Auto-retry mode enables you to select up to ten retries and an interval of up to eight hours between retries.
  10. Click Schedule to start creating the backup artifact.
  11. Go to the All Backups tab, and check the Status column. An animated ellipsis indicator shows that a backup is currently being created.

PITR artifacts

The PITR oplog is available a few minutes (10 by default) after your PITR job has run for the first time. To see the corresponding PITR artifact, check out the list under Backup > All Backups.

PITR and other scheduled backups

Make sure to disable any other scheduled backup jobs before creating a PITR backup. PMM displays an error message if you try to enable PITR while other scheduled backup jobs are active:

This constraint applies at the service level. You can still have PITR enabled for one service while having regular scheduled backup jobs for other services.


Last update: 2023-03-30