Percona Backup for MongoDB v1.5 Released

Percona Backup for MongoDB (PBM) has reached a new step with the release of version 1.5.0 today, May 13th, 2021.

Azure Blob Storage Support

Now you can use Azure Blob Storage as well as S3-compatible object stores.

Configuration example:

Preference Weight for Backup Source Nodes

Until now PBM would use a secondary as a backup source if there is one with a pbm-agent on it, otherwise, as a fall-back, it will use a primary.

There are, however, plenty of users who would like a certain mongod node, for example, those in a datacenter closer to the backup storage, to be the preferred mongod nodes to copy the data from. This is only a preference – if the user-preferred node is down then another one will be chosen.

Setting the priority section is entirely optional. If you don’t specify any preferences PBM will choose this way by default: Hidden secondaries are top preference (PBM-494), normal secondaries are next, primaries are last.

Configuration example of manually-chosen priorities:

The default preference weight is 1.0, so other nodes not explicitly listed above will have a priority above that of the “mdb-s1n3.bc.net:27017” example node above.

You can not set priority to <= 0 value as a way to ban a node. A banned mongod node might be the last healthy one at a given moment and the backup would fail to start, so a design decision to exclude the banning of nodes was made.

Important note: as soon as you begin specifying any node preference it is assumed you are taking full manual control. At this point the default rules, eg. to prefer secondaries to primaries, stop working.

Users and Roles Backup Method Change

Important notice for database administrators: The backup file format for v1.5 has an incompatible difference with v1.4 (or earlier) backups. v1.5 will not be able to restore backups of v1.4.x or earlier.

Restoring users and roles has some constraints. To prevent a collection drop of system.users or system.roles disrupting the pbm-agent <-> mongod connection, they are not re-inserted under their original collection name. Instead, they are inserted into a temporary location and the user and role records are copied one by one.

A catch with the point in time previously used to rename the collections to temporary names has interfered with a requirement regarding restoring collection UUIDs, which in turn blocked a fix of bug PBM-646.

Because PBM uses a single archive file for each full snapshot backup, there is no way to fix the embedded collection names in the backups for v1.4 before the restore process begins. This means there is no workaround that will allow v1.5 PBM to restore <= v1.4.x PBM backups.

The only workaround to restore <= 1.4.x backups after deploying v1.5 would be to roll back PBM executables (pbm and pbm-agent) to v1.4.1 just for the restore.

Bug Fixes

• PBM-636: Restores of sharded collections needed to be fixed by setting the same UUID value. Thanks to Nikolay and Dmitry for reporting the issue.
• PBM-646 – Stop the balancer during backup to make sure it doesn’t start running during restore.
• PBM-642 – Display priority=0 members on agent list in PBM Status output.