Questions Regarding PBM 2.14 Backup Cleanup and PITR Behavior

MongoDB Percona Backup for MongoDB
, ,
1

Hello,

I have a few questions regarding PBM version 2.14.

We are using PBM in both MongoDB replica set (Primary-Secondary-Arbiter) and sharded cluster environments. We perform a logical backup once per day and run PITR backups every 10 minutes.

However, I noticed an issue with the cleanup functionality. When I run the pbm cleanup --older-than command in PBM 2.14, it always returns “nothing to do”.

For example, assume the following backups exist:

  • Backup taken on June 2, 2026
  • Backup taken on June 4, 2026

If I execute:

pbm cleanup --older-than "2026-06-03"

I would expect the June 2 backup to be removed, but instead the command outputs “nothing to do” and no deletion occurs.

The same behavior occurs when using pbm delete backup. However, if I explicitly specify the backup name using:

pbm delete-backup <backup_name>

the backup is deleted successfully.

I also noticed that when running pbm status or pbm list, the Base column shows “No” for all backups. This seems related to the issue.

My questions are:

  1. Why does pbm cleanup --older-than not remove older backups and return “nothing to do”?
  2. Is this behavior related to the Base = No status shown in pbm status and pbm list?
  3. Since we are creating logical backups, why are they displayed as Base = No rather than Base = Yes?
  4. We are running PITR continuously and also performing a full logical backup every day. When viewing the PITR restore ranges (for example, in pbm list or related commands), the entries appear to be listed starting from the oldest available point in time rather than from the most recent full backup. Could you explain why the PITR ranges are displayed in this order and whether this is the expected behavior?

Below is a sample output from pbm status for reference.

Any advice or clarification would be greatly appreciated.

Thank you.

2

Hello @dasol, thanks for reaching out. Regarding your questions

1: pbm cleanup --older-than performs additional consistency checks across snapshot and PITR chunks with respect to the cutoff date. Meaning if you want to delete items older than June 3rd, there might be PITR chunks for June 3rd for which the snapshot backup is the still the one from June 2nd. Think this timeline

June 2nd
Snapshot 2026-06-02T08:48:28Z
PITR_chunk1
PITR_chunk2

June 3rd
PITR_chunk3
Snapshot 2026-06-03T08:48:28Z
PITR_chunk4
PITR_chunk5

June 4th
Snapshot 2026-06-04T08:48:28Z

Here PITR_chunk3 is from June 3rd so it is not supposed to be deleted and since PBM needs to keep this chunk restorable it cannot delete its snapshot and any chunks in between.

2, 3: No, the Base column is representation of incremental backup base (which is a physical backup)

4: Yes, a continuous PITR timeline is displayed from the oldest Point in Time. Unless --base-snapshot is specified for pbm restore the latest available snapshot will be used (thus minimizing the size of oplog replay). In certain use cases you might want to chose your snapshot or even perform oplog replay only (but that’s very specific scenario involving oplog-replay command). So this is intentional

Hope this helps!