v2.12.0

• Integrate your backup workflows into the Alibaba Cloud ecosystem seamlessly using Alibaba Cloud Object Storage Service (OSS) as the remote backup storage. Authenticate to Alibaba Cloud OSS directly using your AccessKey pair, or ensure compliance with your org's security policies with a full support for Alibaba Cloud's Security Token Service (STS) AssumeRole, which includes automatic security token refresh. This integration empowers teams operating in Asia-Pacific or invested in Alibaba Cloud to adopt PBM better. Read more about Alibaba Cloud OSS support in our documentation

• Ensure data upload to Azure Blob storage even during unstable network. You can now control the number of upload retries to Azure in PBM configuration. This enhancement ensures your data reaches its destination—even when the network is unstable or intermittent. Check PBM configuration file reference for available options.

• Improved usage of custom S3-compatible storage service implementations with a native support for MinIO client library in PBM. To prevent potential compatibility and connectivity issues if anS3-compatible storage service doesn't support Signature Version 4 (SigV4) used in AWS SDK v2, PBM now uses the MinIo Go client and supports a new minio storage type in its configuration. If your custom S3-compatible storage is not compatible with AWS SDK v2, consider re-configuring PBM to use the minio storage type after the upgrade. Check the documentation for steps. Also, be aware of the current known limitation that currently PBM uploads backups in a single thread which may result in slower performance.

• Deprecation of HMAC keys support for Google Cloud Storage. Google Cloud Storage doesn't support a new Signature Version 4 (SigV4) and only supports SigV2 for HMAC authentication. Signature Version 2 (SigV2) authentication is not recommended because it lacks important security enhancements, is no longer maintained, and can introduce critical reliability issues. To prevent these, HMAC support in PBM is deprecated and will be removed in the release following after April 30, 2026. We strongly recommend migrating to a native GCS connection type with JSON keys. Refer to the documentation for guidance on adjusting PBM configuration to use JSON keys.

v2.11.0

Ensure successful upload of any size backup

When backup files are so large that they exceed the object size limit for backup storage, PBM now splits such files into pieces that fall within the size limit and uploads them to the storage. PBM names these pieces to identify and manage them later. The reverse process occurs during the data read for a restore: PBM merges the pieces into a single file and proceeds with the command execution. You can redefine the default size limit using PBM configuration and ensure your backups are uploaded regardless of the size. Learn more about how to do it in the documentation.

Dropped support of MongoDB 6.0

Percona Backup for MongoDB drops support of MongoDB 6.0. Existing functionality in Percona Backup for MongoDB remains compatible with MongoDB 6.0 and Percona Server for MongoDB 6.0; however, further enhancements and bug fixes are no longer tested against this version.

Known limitations for using HMAC keys on GCS

In PBM version 2.10.0 and higher, when you run backups to GCS via HMAC keys, incomplete backups may be incorrectly marked as successful if network interruptions occur during the backup process. This results in corrupted or partially uploaded archives being stored and treated as valid backups, which can later fail during restore operations. This issue is addressed in PBM-1605. Until the issue is resolved, we recommend using a native GCS connection type with JSON keys rather than HMAC keys to ensure backup integrity.

v2.10.0

• Ensure your cluster remains operational even if errors occur during a physical restore by making restores with a fallback directory. PBM copies the dbPath contents to a special fallback directory at the restore start and proceeds with the restore as usual. If an error occurs during the restore, PBM uses the fallback directory contents to roll back the cluster to its pre-restore state. Note that to use this feature you must have enough free disk space on each mongod instance to store the dbPath contents.

• Improved compatibility with Google Cloud Storage (GCS) by using a native Google Cloud Client library. PBM communicates with GCS both via JSON API and XML API and supports both types of credentials: storage account credentials for JSON API and HMAC keys for XML API requests. The use of a new library resulted in PBM configuration changes which you need to when you upgrade to this PBM version. Read more about these steps in the documentation.

• 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.

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

v2.9.1

• Fixed the issue in PBM unable to take physical backup in deployments with MongoDB Community and Percona Server for MongoBD (PBM-1512)

v2.9.0

• Percona Backup for MongoDB is now available and fully supported on Amazon Linux 2023 (AL23), simplifying its AWS deployment. You can safely run PBM on AL23 to build a secure, stable, high-performance environment for developing and running cloud applications, with seamless integration with various AWS services and development tools.

• You can now define a pbm-agent configuration in a single file and start the agent using it. The configuration includes the MongoDB connection URI, the custom log path, and the number of parallel workers needed for a backup. In addition, you can adjust the log level on runtime without restarting the pbm-agent. This helps you keep all your pbm-agent setup in a single place and simplifies its management. Learn more about how to start pbm-agent using the configuration file as well as all the ways to configure a custom log path

• Percona Backup for MongoDB Docker image is now based on Universal Base Image (UBI) version 9, which includes the latest security fixes. This makes the image compliant with the Red Hat certification and ensures the seamless work of containers on Red Hat OpenShift Container Platform.

• Removed kingpin dependency from PBM CLI (PBM-1466)

• The balancer is stopped and chunks are autosplit automatically during restore (PBM-1452)

• Fixed failing selective backup/restore for sharded collections in setups with config shards (PBM-1465)

• Allow PBM operation on server with a single CPU by auto-adjusting the number of parallel collections to 1 (PBM-1478)

• Fixed the issue with failing restores when there are collections partial indexes by storing all index types in backup metadata (PBM-1479)

• Fixed the issue with pbm-agent starts by fixing the typo in pbm-agent.init file (PBM-1485)

v2.8.0

• Better organization of selective backups by defining multiple namespaces when making a backup. A single backup for multiple namespaces instead of backups per namespace also enables you to save on disk space.

• Control communication between pbm-agents residing behind different network settings and remote backup storage. This ensures proper functioning of PBM.

• Simplified troubleshooting with restoring the same collection under a different name. The restored collection has the same data and indexes as the one you backed up. This makes it easier to compare the data in both collections and identify what caused the issue with the database.

• Reduce troubleshooting time with the diagnostics report. Use the pbm diagnostic command to collect comprehensive information about a command execution and generate a report. Either dive deep yourself or file a bug report to our experts and attach the diagnostics archive to it.

• Improved log rotation with a custom path for log output. Outputting log information to a file at a custom path enables you to introduce log rotation, manage the system log effectively and comply to security regulations for logging and auditing.

• Additional flexibility for backups is achieved with replacing mongodump with PBM's own dump implementation. This lifts the mongodumps' limitations and opens space for further improvements.

• Added support of Percona Server for MongoDB 8.0 and MongoDB Community 8.0.

• Dropped support of Percona Server for MongoDB 5.0 and MongoDB Community 5.0 as it entered the end-of-life stage. Existing functionality remains compatible with version 5.0. However, we will no longer test new features and improvements against this version.

v2.7.0

Single authentication point for PBM running in Amazon EKS - Now PBM running in Amazon Elastic Kubernetes Service (EKS) can access AWS services using the credentials from the IAM role associated with the service account that is assigned to the Pod where PBM is running. Since with this improvement you don’t have to pass the credentials to every individual Pods, the overall security of your infrastructure increases.

Consider the following limitation if you run Percona Operator for MongoDB: a restore does not work with this feature without the modification of default serviceAccount. It will be improved in future releases of the Operator to cover this case.

v2.6.0

• PBM support multiple storages for backups and restores and can make a backup to the storage of your choice. This ability helps you save on data transfer costs when using cloud storage, as well as enables you to follow closely with the requirements of your organization’s backup policy.
• You can now adjust node priorities for point-in-time recovery oplog slices helping you to reduce network latency
• Configure the waiting time for a command execution via the --wait-time flag for PBM commands
• Snapshot-based backups are GA

2.5.0

• Ability to restore the desired subset of custom databases with users and roles created in them. This is useful for deployments where each user has an individual database and authenticates against it.
• Previous versions of PBM required that readConcern and writeConcern are set to majority in MongoDB. You can now explicitly override this behavior, and thus, ensure backups in clusters configured to operate without the majority or lost it for some reason.

2.4.0

• Added ability to delete backup snapshots of a specific type. For example, delete only logical backups which you might have created and no longer need.

• Ability to check what exactly will be deleted with the new --dry-run flag.

• Point-in-time recovery oplog slicing is now running in parallel with backup snapshots. This ensures point-in-time recovery to any timestamp from very large backups that take hours to make.

• Percona Backup for MongoDB packages are now also available for ARM64 architectures for the following operating systems:

  • Ubuntu 20.04 (Focal Fossa)
  • Ubuntu 22.04 (Jammy Jellyfish)
  • Red Hat Enterprise Linux 8 and compatible derivatives
  • Red Hat Enterprise Linux 9 and compatible derivatives