Releases: percona/pbm-docs
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
andwriteConcern
are set tomajority
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
2.3.1
- Added support for Percona Server for MongoDB 7.0.
- The ability to define custom endpoints when using Microsoft Azure Blob Storage for backups
- Improved PBM Docker image to allow making physical backups with the shared
mongodb
data volume - Updated Golang libraries that include fixes for the security vulnerability CVE-2023-39325.
2.3.0
- The support for MongoDB 4.2 is deprecated. Existing functionality in Percona Backup for MongoDB remains compatible with MongoDB 4.2 and Percona Server for MongoDB 4.2; however, further enhancements and bug fixes are no longer tested against this version.
- The ability to view the backup contents improves troubleshooting of backups in environments where databases are often created and / or dropped.
- The ability to make physical backups in mixed deployments with MongoDB Community and Percona Server for MongoDB (PSMDB) nodes streamlines the backup flow for organizations that are still evaluating or migrating their data sets against PSMDB.
2.2.1
- Configurable wait time for PBM to start a physical backup
2.2.0
- Point-in-time recovery from physical backups is now automated similar to point-in-time recovery from logical ones. This offloads your DBAs on performing manual oplog replay on top of physical restore, ensures data consistency and unifies the user experience with PBM.
- Owners of large data sets can now use PBM to create external physical backups as EBS snapshots or via a technology of their choice and restore from those backups with the data consistency guaranteed by PBM. Thereby they benefit from increased performance and reduced downtime, and are sure that their data remains consistent. This is the technical preview feature.
- The ability to restore from physical and incremental backups to a new environment with different replica set names extends the set of compatible environments for physical restore.
2.1.0
- Incremental physical backups are GA. Backups made with previous PBM versions are incompatible for restore with PBM 2.1.0
- Support of sharded collections for selective backups and restores. Sharded timeseries collections are not supported
- Support of parallel download of data from S3 compatible storage for physical restore
- pbm cleanup command to delete old backups and PITR chunks for a defined time period.
- Improved physical restore of data encrypted at rest: now master key rotation using the same key is possible for Vault.
- Support of AWS tokens for S3 storage access.