# Questions Regarding PBM 2.14 Backup Cleanup and PITR Behavior **URL:** \ **Category:** Percona Backup for MongoDB\ **Tags:** community, percona, mongodb\ **Created:** [June 6, 2026, 12:15am UTC](https://forums.percona.com/t/questions-regarding-pbm-2-14-backup-cleanup-and-pitr-behavior/40878 "2026-06-06T00:15:13Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![dasol](https://avatars.discourse-cdn.com/v4/letter/d/ed655f/32.png) [@dasol](https://forums.percona.com/u/dasol)\ **Post date:** [June 6, 2026, 12:15am UTC](https://forums.percona.com/t/questions-regarding-pbm-2-14-backup-cleanup-and-pitr-behavior/40878/1 "2026-06-06T00:15:13Z")
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: ```auto 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: ```auto pbm delete-backup ``` 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. ---
**Author:** ![Jakub\_Cechacek](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jakub_cechacek/32/22576_2.png) [@Jakub\_Cechacek](https://forums.percona.com/u/Jakub_Cechacek)\ **Post date:** [June 8, 2026, 9:07am UTC](https://forums.percona.com/t/questions-regarding-pbm-2-14-backup-cleanup-and-pitr-behavior/40878/2 "2026-06-08T09:07:40Z")
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!