Percona Backup for MongoDB 2.10.0 (2025-06-26)¶

Installation

Percona Backup for MongoDB is a distributed, low-impact solution for creating consistent backups of MongoDB sharded clusters and replica sets, and for restoring those backups to a specific point in time.

Release Highlights¶

This release provides the following features and improvements:

Fallback strategy for physical restores to ensure cluster operation¶

You can now configure PBM to use a fallback directory during a physical restores. At the restore start, PBM copies the dbPath contents to a special fallback directory. Then, the restore flows as usual.

If the restore is successful, PBM deletes the fallback directory. If PBM detects that the cluster is in an error state, it triggers the fallback procedure and restores the cluster to its pre-restore state. This ensures your cluster remains operational, allowing you to retry the restore from another backup or perform other maintenance tasks.

Note that this functionality requires sufficient free disk space on each mongod instance to store the dbPath contents. At the restore start, PBM checks the available disk space and logs this information.

With this feature, your cluster can remain operational even if errors occur during a physical restore. For more details about the fallback flow and configuration, see the documentation.

Improved security via the updated libraries¶

Percona Backup for MongoDB now uses the AWS SDK v2 for Go, which includes the latest features, security updates and improvements. This ensures the secure communication with AWS services.

Support of Google Cloud Client library¶

PBM now supports Google Cloud Client Library for interacting with Google Cloud Storage (GCS). PBM communicates with Google Cloud Storage (GCS) via the JSON API and XML API. The preferred approach is to use the JSON API with a service account. HMAC keys are mainly used for compatibility with S3-style APIs.

Note that PBM configuration for a backup storage now has a dedicated gcs subsection. If you’re upgrading to PBM 2.10.0 or later, you must update your backup configuration accordingly:

Change the storage.type from s3 to gcs.
Change the storage.s3 section to storage.gcs and adjust the parameters accordingly.

Read more about available options in the Google Cloud Storage (GCS) chapter.

This integration offers improved compatibility, more predictable API responses and better long-term support for GCS features.

Packaging changes¶

Percona Backup for MongoDB is no longer supported on Ubuntu 20.04 (Focal Fossa) as this operating system has reached end of life.

Changelog¶

New Features¶

PBM-1506 - Add support for concurrent downloading of the single file for GCS
PBM-1507, PBM-1511 - Add the ability to make physical restores with a fallback directory to ensure cluster operation

Improvements¶

PBM-772 - Use the “hello” command instead of “isMaster”
PBM-1474 - Swap AWS SDK API s3 from v1 to v2
PBM-1481 - Remove the “Z” marker in the restore timestamps in pbm list and pbm status outputs (Thank you Nathan Neulinger for reporting this issue)
PBM-1484 - Use a dedicated Google Cloud Storage SDK Go library instead AWS SDK v1
PBM-1498 - Add HMAC support for GCS SDK
PBM-1514 - Improve resync performance for restores by retrieving only the latest record from the storage and introducing a flag to retrive the full history
PBM-1544 - Add a new “Status” column to pbm status output to explicitly show a backup status

Bugs Fixed¶

PBM-1238 - Fixed the error of reading the timestamp from a cluster heartbeat when parsing the physical restore status from a metadata file. If that field is missing, uninitialized, or improperly formatted in the database, the parsing fails. The issue is fixed by processing the timestamp from the metadata file if it exists
PBM-1401 - Added support for the --wait flag for the pbm config --file and pbm config --set commands. When running these commands immediately followed by another operation such as start backup, using the --wait flag is the correct and recommended approach to ensure the storage is fully synchronized before running the next command
PBM-1439 Fixed the issue with a backup failing due to the maxUploadParts setting being ignored during part size calculation for instances where the size was unknown. The issue is fixed by estimating oplog slice size using bytes/sec × duration with extra growth and a 1 GiB minimum (Thank you Rama Mekala for reporting this issue)
PBM-1482 - Fixed issues with selective restores due to unclosed files causing S3 deadlocks and incomplete processing of config.chunks collection due to single-batch processing
PBM-1483 - Fixed unhandled error that might occur when files are deleted and listed in parallel on filesystem storage by adding proper error handling in such cases
PBM-1487 - Fixed the issue with mongos failing with during full logical restore and point-in-time recovery from a logical backup if the target cluster has the databases that are also present in the backup and the cache was not updated leading to the Time monotonicity violation error. The issue was fixed by introducing the cleanup phase, during which PBM cleans up all databases and internal caches that are present in the backup, thus making the cluster clean for the rest of the restore procedure
PBM-1494 - Fixed the s3 URI format in pbm status output
PBM-1499 - Improve the error message in the restore metadata to contain the actual error instead of a placeholder
PBM-1501, PBM-1531 - Fixed the issue with hanging incremental restores caused by a deadlock that happens within buffered logger (Thank you Danila Terekhov for reporting this issue)
PBM-1502 - Fixed the issue with failing profile syncing
PBM-1519 - Fixed logging for physical restore by removing the message about the db connection error when MongoDB is down as part of the physical restore process
PBM-1522 - Fixed the issue with incorrect restore of users during selective restore if the database name starts with the admin by checking the full database name instead of the prefix (Thank you Tomasz Spyrka for reporting this issue and contributing to it)
PBM-1523 - Fixed the issue with the PBM’s system collections: pbmCmd, pbmLog, pbmConfig are not excluded from selective restore (Thank you Tomasz Spyrka for reporting this issue and contributing to it)
PBM-1538 - Fixed an issue where backups were incorrectly marked as successful even if oplog uploads failed
PBM-1550 - Fixed the issue with PBM starting a point-in-time restore despite the missing oplog chunk for the specified time
PBM-1551 - Fixed an issue with PBM reissuing the previously executed command by pbm-agent remembering every command it has seen, grouped by timestamp, and ignoring repeats that share both timestamp and command
PBM-1553 - Improved mongod restart procedure and logging during physical restore to fix failing restores on the clean-up and reset replicaset config stages
PBM-1564 - Fixed the issue with incremental backups failing with the error “source backup is stored on a different storage” by improving the storage identity checks so that only the properties that identify the storage such as region, bucket name or prefix path are checked

Last update: September 25, 2025
Created: September 25, 2025