Skip to content
logo
Percona Backup for MongoDB
Physical backups and restores
Initializing search
    percona/pbm-docs
    percona/pbm-docs
    • Home
        • Overview
        • Logical backups and restores
        • Physical backups and restores
          • Availability and system requirements
          • Physical restores with data-at-rest encryption
            • Restore for Percona Server for MongoDB before 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault
        • Selective backup and restore
        • Incremental physical backups
        • Point-in-time recovery
      • Comparison with MongoDB
      • How PBM works
        • PBM architecture
        • pbm-agent
        • PBM CLI
        • PBM control collections
          • Overview
          • Remote backup storage configuration examples
      • Authentication
      • Supported MongoDB deployments
      • Supported MongoDB versions
        • Overview
        • Method 1. From repositories
        • Method 2. Build from source
        • Method 3. Download tarballs
        • Method 4. Deploy on Kubernetes
      • Set up and configure
      • Make a backup
      • Restore a backup
      • Make a point-in-time restore
      • List backups
      • View detailed information about a backup
      • Schedule backups
      • Cancel a backup
      • Delete backups
      • View restore progress
      • Replay oplog from arbitrary start time
      • View backup logs
      • PBM configuration via pipelines
      • Automate access to S3 buckets for PBM
      • Diagnose PBM
      • Check status
      • Upgrade PBM
      • Remove PBM
    • FAQ
      • PBM commands
        • Configuration file
        • Remote backup storage options
        • Point-in-time recovery options
        • Backup options
        • Restore options
      • Glossary
      • Release notes index
      • Percona Backup for MongoDB 2.1.0 (2023-04-18)
      • Percona Backup for MongoDB 2.0.5 (2023-03-23)
      • Percona Backup for MongoDB 2.0.4 (2023-02-21)
      • Percona Backup for MongoDB 2.0.3 (2023-01-11)
      • Percona Backup for MongoDB 2.0.2 (2022-10-27)
      • Percona Backup for MongoDB 2.0.1 (2022-10-12)
      • Percona Backup for MongoDB 2.0.0 (2022-09-21)
      • Percona Backup for MongoDB 1.8.1 (2022-07-12)
      • Percona Backup for MongoDB 1.8.0 (2022-06-09)
      • Percona Backup for MongoDB 1.7.0 (2022-04-18)
      • Percona Backup for MongoDB 1.6.1 (2021-11-04)
      • Percona Backup for MongoDB 1.6.0 (2021-08-16)
      • Percona Backup for MongoDB 1.5.0 (2021-05-10)
      • Percona Backup for MongoDB 1.4.1 (2021-01-28)
      • Percona Backup for MongoDB 1.4.0 (2020-12-24)
      • Percona Backup for MongoDB 1.3.4 (2020-11-19)
      • Percona Backup for MongoDB 1.3.3 (2020-11-04)
      • Percona Backup for MongoDB 1.3.2 (2020-10-14)
      • Percona Backup for MongoDB 1.3.1 (2020-09-03)
      • Percona Backup for MongoDB 1.3.0 (2020-08-26)
      • Percona Backup for MongoDB 1.2.1 (2020-07-27)
      • Percona Backup for MongoDB 1.2.0 (2020-05-13)
      • Percona Backup for MongoDB 1.1.3 (2020-04-14)
      • Percona Backup for MongoDB 1.1.1 (2020-01-31)
      • Percona Backup for MongoDB 1.1.0 (2020-01-16)
      • Percona Backup for MongoDB 1.0.0 (2019-09-19)
      • Percona Backup for MongoDB 0.5.0 (2019-06-17)
    • Contribution guidelines
    • Copyright and licensing
    • Trademark policy

    • Availability and system requirements
    • Physical restores with data-at-rest encryption
      • Restore for Percona Server for MongoDB before 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault

    Physical backups and restores¶

    Version added: 1.7.0

    Availability and system requirements¶

    • Percona Server for MongoDB starting from versions 4.2.15-16, 4.4.6-8, 5.0 and higher.
    • WiredTiger is used as the storage engine in Percona Server for MongoDB, since physical backups heavily rely on the WiredTiger $backupCursor functionality.

    See also

    Percona Blog

    • Physical Backup Support in Percona Backup for MongoDB
    • $backupCursorExtend in Percona Server for MongoDB

    Physical backup is copying of physical files from the Percona Server for MongoDB dbPath data directory to the remote backup storage. These files include data files, journal, index files, etc. Starting with version 2.0.0, Percona Backup for MongoDB also copies the WiredTiger storage options to the backup’s metadata.

    Physical restore is the reverse process: pbm-agents shut down the mongod nodes, clean up the dbPath data directory and copy the physical files from the storage to it.

    The following diagram shows the physical restore flow:

    image

    During the restore, the pbm-agents temporarily start the mongod nodes using the the WiredTiger storage options retrieved from the backup’s metadata. The logs for these starts are saved to the pbm.restore.log file inside the dbPath. Upon successful restore, this file is deleted. However, it remains for debugging if the restore were to fail.

    During physical backups and restores, pbm-agents don’t export / import data from / to the database. This significantly reduces the backup / restore time compared to logical ones and is the recommended backup method for big (multi-terabyte) databases.

    Advantages Disadvantages
    - Faster backup and restore speed
    - Recommended for big, multi-terabyte datasets
    - No database overhead
    - The backup size is bigger than for logical backups due to data fragmentation extra cost of keeping data and indexes in appropriate data structures
    - Extra manual operations are required after the restore
    - Point-in-time recovery requires manual operations

    Make a backup Restore a backup

    Physical restores with data-at-rest encryption¶

    Version added: 2.0.0

    You can back up and restore the encrypted data at rest. Thereby you ensure data safety and can also comply with security requirements such as GDPR, HIPAA, PCI DSS, or PHI.

    This is how it works:

    During a backup, Percona Backup for MongoDB stores the encryption settings in the backup metadata. This allows you to verify them using the pbm describe-backup command. Note that the encryption key is not stored nor shown.

    Important

    Make sure that you know what master encryption key was used and store it, as this key is required for the restore.

    Starting with Percona Server for MongoDB version 4.4.19-19, 5.0.15-13, 6.0.5-4 and higher, the master key rotation for data-at-rest encrypted with HashiCorp Vault has been improved to use the same secret key path on every server in your entire deployment. For the restore with earlier versions of Percona Server for MongoDB and PBM 2.0.5 and earlier, see the Restore for Percona Server for MongoDB before 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault section.

    To restore the encrypted data from the backup, configure data-at-rest encryption settings on all nodes of your destination cluster or replica set to match the settings of the target cluster where you made the backup

    During the restore, Percona Backup for MongoDB restores the data all nodes using the same master key. To meet the security policy requirements in your organization, we recommend to rotate the master encryption keys afterwards.

    To learn more about master key rotation, refer to the following documentation:

    • Master key rotation in HashiCorp Vault server
    • KMIP master key rotation

    Restore for Percona Server for MongoDB before 4.4.19-19, 5.0.15-13, 6.0.5-4 using HashiCorpVault¶

    In Percona Server for MongoDB version before 4.4.19-19, 5.0.15-13, 6.0.5-4 with the Vault server used for data-at-rest encryption, the master key rotation with the same key used for 2+ nodes is not supported. If you run these versions of Percona Server for MongoDB and PBM before 2.1.0, consider using the scenario where PBM restores the data on one node of every replica set. The remaining nodes receive the data during the initial sync.

    Here’s how it works:

    Configure data-at-rest encryption on one node of every shard in your destination cluster or a replica set.

    During the restore, Percona Backup for MongoDB restores the data on the node where the encryption key matches the one with which the backed up data was encrypted. The other nodes are not restored, so the restore has the “partially done” status. You can start this node and initiate the replica set. The remaining nodes receive the data as the result of the initial sync from the restored node.

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: May 31, 2023
    Created: May 31, 2023
    Percona LLC and/or its affiliates, © 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.