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 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:

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:

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