From 93792cb19c05a55ac39b5cb51652fbacbc6449b5 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 15:14:47 +0530 Subject: [PATCH 01/16] PBM-1731 GFS Rotation & Retention to PBM --- docs/usage/backup-lifecycle-management .md | 299 +++++++++++++++++++++ mkdocs-base.yml | 1 + 2 files changed, 300 insertions(+) create mode 100644 docs/usage/backup-lifecycle-management .md diff --git a/docs/usage/backup-lifecycle-management .md b/docs/usage/backup-lifecycle-management .md new file mode 100644 index 00000000..76dd4202 --- /dev/null +++ b/docs/usage/backup-lifecycle-management .md @@ -0,0 +1,299 @@ +# Backup lifecycle management + +2026-09-22 · @Rasika Chivate + +Backup lifecycle management rotates your backups for you. You define a retention policy once, and Percona Backup for MongoDB (PBM) purges aged backups while it protects the restore points you depend on. The feature follows the Grandfather-Father-Son (GFS) rotation scheme, which holds three tiers at the same time: + +- Daily backups, for immediate disaster recovery +- Weekly backups, for short-term historical rollback +- Monthly backups, as long-term anchors for audits + +A GFS policy replaces the `cron` and `pbm delete-backup` scripts that many teams maintain by hand. Unlike a script, the engine checks point-in-time recovery (PITR) chains and running backups before a purge. + + +!!! note + + Lifecycle management is turned off after an upgrade. PBM deletes nothing until you set `lifecycle.enabled` to `true`. + + +## How rotation works + +A backup passes through three stages as the backup ages. + +### The daily window + +The `dailyRetention` option defines a keep-everything zone, measured backward from the run time. Every successful backup inside the window stays, with no bucketing. A value of `7` with a backup every six hours keeps all 28 backups. + +### The weekly and monthly windows + +Past the daily window, PBM groups backups into buckets and keeps one backup per bucket. The `strategy` option decides how the grouping works. + +| Strategy | Grouping method | Best for | +| --- | --- | --- | +| `rolling` (default) | Time decay. PBM divides the timeline into seven-day and 30-day chunks, then keeps the newest backup in each chunk. | Cloud deployments and schedules that drift. A paused or failed backup job costs you nothing, since PBM keeps the closest available backup in the window. | +| `calendar` | Strict anchoring. PBM keeps backups taken on the exact days named by `weeklyDay` and `monthlyDay`. | Finance, healthcare, and any audit that names a date, such as the end-of-month state of the database. | + + +!!! note + + Under the `calendar` strategy, a missed anchor date has a fallback. If no backup exists for the 15th, PBM scans that month and keeps the closest backup, such as the one from the 14th or the 16th. + + +## Mixed backup types + +Many deployments take both physical and logical backups. The bucketing engine sorts candidates into separate lanes by type, so one type never crowds out another. Each week and each month keeps its own logical, physical, and incremental anchor. The rule applies to the global configuration and to storage profiles alike. + + +!!! note + + Type separation protects both backup types, but long-term archives of both consume storage. To keep physical backups for a year and logical backups for three days, use separate storage profiles. + + +## Configuration options + +The `lifecycle` block in the PBM configuration controls the feature: + +| Option | Type | Default | Description | +| --- | --- | --- | --- | +| `lifecycle.enabled` | Boolean | `false` | Turns on automated rotation. While the value stays `false`, PBM purges nothing. | +| `lifecycle.strategy` | String | `rolling` | Sets the rotation algorithm. Values: `rolling` or `calendar`. | +| `lifecycle.minKeep` | Integer | `1` | Circuit breaker. PBM aborts the whole rotation if a purge drops the count of kept backups below this number. | +| `lifecycle.prompt` | Boolean | `true` | Prints the keep and purge lists and waits for a `[y/N]` answer. Set to `false` for `cron` jobs. | +| `lifecycle.purgeFailed` | Boolean | `false` | Controls failed and canceled backups. `false` protects them without a time limit. `true` keeps them for the length of the daily window, then deletes them. | +| `lifecycle.dailyRetention` | Integer | `0` | Number of days to keep every completed backup. Set to `0` to turn the tier off. | +| `lifecycle.weeklyRetention` | Integer | `0` | Number of weeks to keep one weekly backup. Set to `0` to turn the tier off. | +| `lifecycle.weeklyDay` | Integer | `0` | Day of the week to target, from `0` for Sunday to `6` for Saturday. Applies to the `calendar` strategy. | +| `lifecycle.monthlyRetention` | Integer | `0` | Number of months to keep one monthly backup. Set to `0` to turn the tier off. | +| `lifecycle.monthlyDay` | Integer | `1` | Day of the month to target, from `1` to `31`. Applies to the `calendar` strategy. | + +Set an option from the command line: + +```bash +pbm config --set lifecycle.dailyRetention=7 +``` + +Or add the block to the PBM configuration file and apply the file: + +```bash +pbm config --file= +``` + +## Example policies + +### Recommended baseline + +For most deployments, start with seven daily, four weekly, and 12 monthly backups under the `rolling` strategy, paired with `purgeFailed: true`. + +Seven days cover the mistake you notice within a week. Four weeks cover silent corruption that nobody caught in time. Twelve months cover audits under standards such as SOC 2, HIPAA, and PCI DSS. + +```yaml +lifecycle: + enabled: false + strategy: "rolling" + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 7 + weeklyRetention: 4 + monthlyRetention: 12 +``` + +### Calendar policy for an audit + +This policy keeps every backup for 14 days, the Friday backup for eight weeks, and the backup from the 15th of the month for six months: + +```yaml +lifecycle: + enabled: false + strategy: "calendar" + purgeFailed: false + dailyRetention: 14 + weeklyRetention: 8 + weeklyDay: 5 + monthlyRetention: 6 + monthlyDay: 15 +``` + + +!!! note + + Both examples start with `enabled: false`. Validate the rules + +## Run a rotation + +A purge deletes data permanently, so PBM separates the decision from the action. The command uses the same connection options, environment variables, and authentication as every other PBM command. + +### Step 1. Validate with a dry run + +The `--dry-run` flag overrides the `enabled: false` safety switch. PBM evaluates the rules against your storage and prints a report. Nothing leaves storage: + +```bash +pbm lifecycle --dry-run +``` + +Output: + +```text +Lifecycle Report (Dry Run: true) +Enabled: false | Strategy: ROLLING | Purge Failed: true +Daily: 7 | Weekly: 4 [Auto (Newest in bucket)] | Monthly: 6 [Auto (Newest in bucket)] + +Backups to KEEP (3): + - 2026-03-26T04:02:01Z + - 2026-03-22T04:02:01Z + - 2026-03-15T04:02:01Z + +Backups to PURGE (2): + - 2026-03-25T04:02:02Z + - 2026-03-24T04:02:01Z +``` + +Check that the oldest restore point you depend on appears under the backups to keep. + +### Step 2. Turn the feature on + +```bash +pbm config --set lifecycle.enabled=true +``` + +### Step 3. Run the rotation + +```bash +pbm lifecycle +``` + +With `prompt: true`, PBM prints the same report and waits for your answer: + +```text +Are you sure you want to permanently delete the purged backups? [y/N]: y +Starting deletion... +Purging backup 2026-03-18T04:02:01Z... +Lifecycle rotation complete. +``` + +To cancel, answer `N` or press `Ctrl+C`. A `Ctrl+C` during the deletion aborts the remaining purges. + +## Separate retention per storage profile + +A policy applies at one of two scopes. + +| Scope | What it covers | Command | +| --- | --- | --- | +| Global | All backups, with the same rules for every backup type | `pbm lifecycle` | +| Profile | Only the backups routed to that profile | `pbm lifecycle --profile=` | + +Use the global scope when one set of rules suits all your data. Use profiles when retention lengths differ, or when buckets in separate regions carry separate compliance rules. A common split keeps physical backups for a year and logical backups for three days. + +### Step 1. Configure the physical profile + +Create `pbm-physical.conf` with the storage settings and the long-term rules: + +```yaml +storage: + type: s3 + s3: + region: us-east-1 + bucket: mongo-physical-backups + prefix: pbm/physical +lifecycle: + enabled: true + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 7 + weeklyRetention: 4 + monthlyRetention: 12 +``` + +```bash +pbm profile add physical-backup pbm-physical.conf +``` + +### Step 2. Configure the logical profile + +Create `pbm-logical.conf` with the short-term rules. A value of `0` turns off the weekly and monthly tiers: + +```yaml +storage: + type: s3 + s3: + region: us-east-1 + bucket: mongo-logical-backups + prefix: pbm/logical +lifecycle: + enabled: true + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 3 + weeklyRetention: 0 + monthlyRetention: 0 +``` + +```bash +pbm profile add logical-backup pbm-logical.conf +``` + +### Step 3. Rotate one profile + +Add the `--profile` flag to evaluate or purge a single profile. PBM ignores the global configuration for that run and tags each kept backup with the tier that saved it, such as `[Daily]` or `[Weekly]`: + +```bash +pbm lifecycle --profile=physical-backup --dry-run +pbm lifecycle --profile=logical-backup --dry-run +``` + +## Automate the rotation + +A daily `cron` job keeps storage under control without manual work. First turn off the interactive prompt, which waits forever in the background, and confirm the circuit breaker: + +```bash +pbm config --set lifecycle.prompt=false +pbm config --set lifecycle.minKeep=1 +``` + +Schedule the run for off-peak hours, away from your backup jobs. The `--out json` flag produces output that a log collector can parse: + +```bash +# Run the rotation every day at 3:00 AM +0 3 * * * /usr/bin/pbm lifecycle --out json >> /var/log/pbm-lifecycle-global.log 2>&1 +``` + +Profiles rotate one at a time: + +```bash +# Long-term physical backups at 2:00 AM +0 2 * * * /usr/bin/pbm lifecycle --profile=physical-backup --out json >> /var/log/pbm-lifecycle-phys.log 2>&1 + +# Short-term logical backups at 2:30 AM +30 2 * * * /usr/bin/pbm lifecycle --profile=logical-backup --out json >> /var/log/pbm-lifecycle-logi.log 2>&1 +``` + + +!!! warning + + Profiles carry their own settings. Set `prompt: false` inside each profile configuration file as well, not only in the global configuration. + + +## Safety checks + +PBM protects recoverability during a rotation with the following guards. + +| Situation | Behavior | +| --- | --- | +| A purge would leave too few backups | The rotation aborts in full when the survivors fall below `minKeep`. | +| A backup is the base for an active PITR chain | PBM refuses the deletion and logs an `ErrBaseForPITR` warning. | +| A backup is in progress | Backups in the `starting`, `running`, or `dumpDone` state stay out of the evaluation. | +| A backup matches several rules at once | PBM flags the backup for each tier and keeps a single copy until the longest window expires. | +| A backup failed or was canceled | `purgeFailed: false` protects the backup without a time limit. `purgeFailed: true` keeps the backup for the length of the daily window, then deletes it. A failed backup never serves as a weekly or monthly anchor. | +| No backup exists on a calendar anchor date | PBM keeps the closest backup from that month. | + +An aborted automated run logs the reason. Review your retention settings when this message appears: + + +!!! WARNING + This rotation would leave you with 0 backup(s), which is below the safety threshold of 1 (minKeep). +Automated run (prompt: false) detected. Purge aborted to protect your backups. + diff --git a/mkdocs-base.yml b/mkdocs-base.yml index 41b595fa..12a0ae5e 100644 --- a/mkdocs-base.yml +++ b/mkdocs-base.yml @@ -230,6 +230,7 @@ nav: - usage/describe-backup.md - usage/schedule-backup.md - usage/cancel-backup.md + - usage/backup-lifecycle-management.md - usage/delete-backup.md - usage/restore-progress.md - usage/backup-priority.md From c343a59c5211d47489f9c59f914a09c4c90efeb1 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 15:19:29 +0530 Subject: [PATCH 02/16] fixed the file name --- ...up-lifecycle-management .md => backup-lifecycle-management.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/usage/{backup-lifecycle-management .md => backup-lifecycle-management.md} (100%) diff --git a/docs/usage/backup-lifecycle-management .md b/docs/usage/backup-lifecycle-management.md similarity index 100% rename from docs/usage/backup-lifecycle-management .md rename to docs/usage/backup-lifecycle-management.md From 11817333215b6cb151e231c59e8ed5a058f45f9b Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 16:28:15 +0530 Subject: [PATCH 03/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 165 ++++++++++------------ 1 file changed, 75 insertions(+), 90 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 76dd4202..e8448c50 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -1,22 +1,8 @@ # Backup lifecycle management -2026-09-22 · @Rasika Chivate +The Backup Lifecycle Management feature automates the retention and rotation of Percona Backup for MongoDB (PBM) backups. This feature allows administrators to define a **Grandfather-Father-Son (GFS)** style retention policy to automatically purge aged data while preserving specific historical recovery points for long-term compliance, disaster recovery, and cost management. -Backup lifecycle management rotates your backups for you. You define a retention policy once, and Percona Backup for MongoDB (PBM) purges aged backups while it protects the restore points you depend on. The feature follows the Grandfather-Father-Son (GFS) rotation scheme, which holds three tiers at the same time: - -- Daily backups, for immediate disaster recovery -- Weekly backups, for short-term historical rollback -- Monthly backups, as long-term anchors for audits - -A GFS policy replaces the `cron` and `pbm delete-backup` scripts that many teams maintain by hand. Unlike a script, the engine checks point-in-time recovery (PITR) chains and running backups before a purge. - - -!!! note - - Lifecycle management is turned off after an upgrade. PBM deletes nothing until you set `lifecycle.enabled` to `true`. - - -## How rotation works +## How retention works A backup passes through three stages as the backup ages. @@ -26,34 +12,30 @@ The `dailyRetention` option defines a keep-everything zone, measured backward fr ### The weekly and monthly windows -Past the daily window, PBM groups backups into buckets and keeps one backup per bucket. The `strategy` option decides how the grouping works. +Past the daily window, Percona Backup for MongoDB (PBM) groups backups into buckets and keeps one backup per bucket. The `strategy` option decides how the grouping works. -| Strategy | Grouping method | Best for | +| **Strategy** | **Grouping method** | **Best for** | | --- | --- | --- | | `rolling` (default) | Time decay. PBM divides the timeline into seven-day and 30-day chunks, then keeps the newest backup in each chunk. | Cloud deployments and schedules that drift. A paused or failed backup job costs you nothing, since PBM keeps the closest available backup in the window. | | `calendar` | Strict anchoring. PBM keeps backups taken on the exact days named by `weeklyDay` and `monthlyDay`. | Finance, healthcare, and any audit that names a date, such as the end-of-month state of the database. | - !!! note Under the `calendar` strategy, a missed anchor date has a fallback. If no backup exists for the 15th, PBM scans that month and keeps the closest backup, such as the one from the 14th or the 16th. - ## Mixed backup types Many deployments take both physical and logical backups. The bucketing engine sorts candidates into separate lanes by type, so one type never crowds out another. Each week and each month keeps its own logical, physical, and incremental anchor. The rule applies to the global configuration and to storage profiles alike. - !!! note Type separation protects both backup types, but long-term archives of both consume storage. To keep physical backups for a year and logical backups for three days, use separate storage profiles. - ## Configuration options The `lifecycle` block in the PBM configuration controls the feature: -| Option | Type | Default | Description | +| **Option** | **Type** | **Default** | **Description** | | --- | --- | --- | --- | | `lifecycle.enabled` | Boolean | `false` | Turns on automated rotation. While the value stays `false`, PBM purges nothing. | | `lifecycle.strategy` | String | `rolling` | Sets the rotation algorithm. Values: `rolling` or `calendar`. | @@ -114,10 +96,9 @@ lifecycle: monthlyDay: 15 ``` - !!! note - Both examples start with `enabled: false`. Validate the rules + Both examples start with `enabled: false`. Validate the rules with a dry run, then turn the feature on. ## Run a rotation @@ -184,66 +165,71 @@ A policy applies at one of two scopes. Use the global scope when one set of rules suits all your data. Use profiles when retention lengths differ, or when buckets in separate regions carry separate compliance rules. A common split keeps physical backups for a year and logical backups for three days. -### Step 1. Configure the physical profile - -Create `pbm-physical.conf` with the storage settings and the long-term rules: - -```yaml -storage: - type: s3 - s3: - region: us-east-1 - bucket: mongo-physical-backups - prefix: pbm/physical -lifecycle: - enabled: true - strategy: rolling - minKeep: 1 - prompt: true - purgeFailed: true - dailyRetention: 7 - weeklyRetention: 4 - monthlyRetention: 12 -``` - -```bash -pbm profile add physical-backup pbm-physical.conf -``` - -### Step 2. Configure the logical profile - -Create `pbm-logical.conf` with the short-term rules. A value of `0` turns off the weekly and monthly tiers: - -```yaml -storage: - type: s3 - s3: - region: us-east-1 - bucket: mongo-logical-backups - prefix: pbm/logical -lifecycle: - enabled: true - strategy: rolling - minKeep: 1 - prompt: true - purgeFailed: true - dailyRetention: 3 - weeklyRetention: 0 - monthlyRetention: 0 -``` - -```bash -pbm profile add logical-backup pbm-logical.conf -``` - -### Step 3. Rotate one profile - -Add the `--profile` flag to evaluate or purge a single profile. PBM ignores the global configuration for that run and tags each kept backup with the tier that saved it, such as `[Daily]` or `[Weekly]`: - -```bash -pbm lifecycle --profile=physical-backup --dry-run -pbm lifecycle --profile=logical-backup --dry-run -``` +### Procedure + +Follow these steps: +{.power-number} + +1. Configure the physical profile + + Create `pbm-physical.conf` with the storage settings and the long-term rules: + + ```yaml + storage: + type: s3 + s3: + region: us-east-1 + bucket: mongo-physical-backups + prefix: pbm/physical + lifecycle: + enabled: true + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 7 + weeklyRetention: 4 + monthlyRetention: 12 + ``` + + ```bash + pbm profile add physical-backup pbm-physical.conf + ``` + +2. Configure the logical profile + + Create `pbm-logical.conf` with the short-term rules. A value of `0` turns off the weekly and monthly tiers: + + ```yaml + storage: + type: s3 + s3: + region: us-east-1 + bucket: mongo-logical-backups + prefix: pbm/logical + lifecycle: + enabled: true + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 3 + weeklyRetention: 0 + monthlyRetention: 0 + ``` + + ```bash + pbm profile add logical-backup pbm-logical.conf + ``` + +3. Rotate one profile + + Add the `--profile` flag to evaluate or purge a single profile. PBM ignores the global configuration for that run and tags each kept backup with the tier that saved it, such as `[Daily]` or `[Weekly]`: + + ```bash + pbm lifecycle --profile=physical-backup --dry-run + pbm lifecycle --profile=logical-backup --dry-run + ``` ## Automate the rotation @@ -271,17 +257,15 @@ Profiles rotate one at a time: 30 2 * * * /usr/bin/pbm lifecycle --profile=logical-backup --out json >> /var/log/pbm-lifecycle-logi.log 2>&1 ``` - !!! warning Profiles carry their own settings. Set `prompt: false` inside each profile configuration file as well, not only in the global configuration. - ## Safety checks PBM protects recoverability during a rotation with the following guards. -| Situation | Behavior | +| **Situation** | **Behavior** | | --- | --- | | A purge would leave too few backups | The rotation aborts in full when the survivors fall below `minKeep`. | | A backup is the base for an active PITR chain | PBM refuses the deletion and logs an `ErrBaseForPITR` warning. | @@ -294,6 +278,7 @@ An aborted automated run logs the reason. Review your retention settings when th !!! WARNING - This rotation would leave you with 0 backup(s), which is below the safety threshold of 1 (minKeep). -Automated run (prompt: false) detected. Purge aborted to protect your backups. + ``` + This rotation would leave you with 0 backup(s), which is below the safety threshold of 1 (minKeep). Automated run (prompt: false) detected. Purge aborted to protect your backups. + ``` From ce4cd4a06e7ae174bdc6487ad74fdfc7a1874516 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 17:07:35 +0530 Subject: [PATCH 04/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 359 ++++++++++++++-------- 1 file changed, 224 insertions(+), 135 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index e8448c50..c4330ed6 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -2,76 +2,134 @@ The Backup Lifecycle Management feature automates the retention and rotation of Percona Backup for MongoDB (PBM) backups. This feature allows administrators to define a **Grandfather-Father-Son (GFS)** style retention policy to automatically purge aged data while preserving specific historical recovery points for long-term compliance, disaster recovery, and cost management. +PBM supports two retention strategies: + +- `rolling` keeps the newest available backup in each retention window. + +- `calendar` keeps backups from configured days of the week or month. + +A lifecycle policy applies to all backups, or to a single storage profile. + +!!! warning + + Lifecycle rotation permanently deletes the backups selected for purging. Run `pbm lifecycle --dry-run` and review the report before you enable rotation. + ## How retention works -A backup passes through three stages as the backup ages. +Three retention tiers make up a policy: -### The daily window +- Daily: keeps every completed backup for the configured number of days. -The `dailyRetention` option defines a keep-everything zone, measured backward from the run time. Every successful backup inside the window stays, with no bucketing. A value of `7` with a backup every six hours keeps all 28 backups. +- Weekly: keeps one backup for each weekly retention window. -### The weekly and monthly windows +- Monthly: keeps one backup for each monthly retention window. -Past the daily window, Percona Backup for MongoDB (PBM) groups backups into buckets and keeps one backup per bucket. The `strategy` option decides how the grouping works. +Set a retention value to `0` to turn that tier off. -| **Strategy** | **Grouping method** | **Best for** | -| --- | --- | --- | -| `rolling` (default) | Time decay. PBM divides the timeline into seven-day and 30-day chunks, then keeps the newest backup in each chunk. | Cloud deployments and schedules that drift. A paused or failed backup job costs you nothing, since PBM keeps the closest available backup in the window. | -| `calendar` | Strict anchoring. PBM keeps backups taken on the exact days named by `weeklyDay` and `monthlyDay`. | Finance, healthcare, and any audit that names a date, such as the end-of-month state of the database. | +For example, with the following settings: -!!! note +```yaml +lifecycle: + dailyRetention: 7 + weeklyRetention: 4 + monthlyRetention: 12 +``` + +PBM keeps every completed backup from the last seven days, with no thinning inside that window. Take a backup every six hours and all 28 stay. Older backups move into the weekly and monthly tiers, where PBM keeps one backup per window and purges the rest. + +### Rolling strategy + +The `rolling` strategy is the default. + +PBM measures the age of a backup from the time the rotation runs, rather than from the calendar date on the backup. Past the daily window, the timeline splits into seven-day windows for the weekly tier and 30-day windows for the monthly tier. PBM keeps the newest backup in each window. + +This behavior helps when backups do not run at the same time every day, or when a scheduled backup is missed. PBM keeps the available backup that fits the window best, so a gap in the schedule does not break the policy. + +```yaml +lifecycle: + strategy: rolling +``` + +### Calendar strategy + +The `calendar` strategy targets configured days of the week and month. - Under the `calendar` strategy, a missed anchor date has a fallback. If no backup exists for the 15th, PBM scans that month and keeps the closest backup, such as the one from the 14th or the 16th. +Use `weeklyDay` to specify the day of the week for weekly retention: -## Mixed backup types +- `0` = Sunday -Many deployments take both physical and logical backups. The bucketing engine sorts candidates into separate lanes by type, so one type never crowds out another. Each week and each month keeps its own logical, physical, and incremental anchor. The rule applies to the global configuration and to storage profiles alike. +- `1` = Monday + +- `2` = Tuesday + +- `3` = Wednesday + +- `4` = Thursday + +- `5` = Friday + +- `6` = Saturday + +Use `monthlyDay` to specify the day of the month, from `1` to `31`. + +??? example + + ```yaml + lifecycle: + strategy: calendar + weeklyRetention: 8 + weeklyDay: 5 + monthlyRetention: 6 + monthlyDay: 15 + ``` + + This configuration targets Friday backups for weekly retention and backups from the 15th of the month for monthly retention. !!! note - Type separation protects both backup types, but long-term archives of both consume storage. To keep physical backups for a year and logical backups for three days, use separate storage profiles. + A calendar policy does not require a backup on the target day. If the 15th has no backup, PBM keeps the closest available backup from that month. -## Configuration options +## Configuration -The `lifecycle` block in the PBM configuration controls the feature: +Configure lifecycle management in the `lifecycle` section of the PBM configuration. | **Option** | **Type** | **Default** | **Description** | | --- | --- | --- | --- | -| `lifecycle.enabled` | Boolean | `false` | Turns on automated rotation. While the value stays `false`, PBM purges nothing. | -| `lifecycle.strategy` | String | `rolling` | Sets the rotation algorithm. Values: `rolling` or `calendar`. | -| `lifecycle.minKeep` | Integer | `1` | Circuit breaker. PBM aborts the whole rotation if a purge drops the count of kept backups below this number. | -| `lifecycle.prompt` | Boolean | `true` | Prints the keep and purge lists and waits for a `[y/N]` answer. Set to `false` for `cron` jobs. | -| `lifecycle.purgeFailed` | Boolean | `false` | Controls failed and canceled backups. `false` protects them without a time limit. `true` keeps them for the length of the daily window, then deletes them. | -| `lifecycle.dailyRetention` | Integer | `0` | Number of days to keep every completed backup. Set to `0` to turn the tier off. | -| `lifecycle.weeklyRetention` | Integer | `0` | Number of weeks to keep one weekly backup. Set to `0` to turn the tier off. | -| `lifecycle.weeklyDay` | Integer | `0` | Day of the week to target, from `0` for Sunday to `6` for Saturday. Applies to the `calendar` strategy. | -| `lifecycle.monthlyRetention` | Integer | `0` | Number of months to keep one monthly backup. Set to `0` to turn the tier off. | -| `lifecycle.monthlyDay` | Integer | `1` | Day of the month to target, from `1` to `31`. Applies to the `calendar` strategy. | - -Set an option from the command line: +| `lifecycle.enabled` | Boolean | `false` | Enables lifecycle rotation. | +| `lifecycle.strategy` | String | `rolling` | Retention strategy. Supported values are `rolling` and `calendar`. | +| `lifecycle.minKeep` | Integer | `1` | Minimum number of backups that must remain after a rotation. PBM aborts the rotation if the number would fall below this value. | +| `lifecycle.prompt` | Boolean | `true` | Prompts for confirmation before deleting backups. Set to `false` when you run lifecycle rotation without interactive input. | +| `lifecycle.purgeFailed` | Boolean | `false` | Controls retention of failed and canceled backups. When `false`, PBM protects them indefinitely. When `true`, PBM keeps them for the `dailyRetention` period. | +| `lifecycle.dailyRetention` | Integer | `0` | Number of days to keep every completed backup. | +| `lifecycle.weeklyRetention` | Integer | `0` | Number of weeks to retain one weekly backup. | +| `lifecycle.weeklyDay` | Integer | `0` | Day of the week to target when `strategy` is `calendar`. | +| `lifecycle.monthlyRetention` | Integer | `0` | Number of months to retain one monthly backup. | +| `lifecycle.monthlyDay` | Integer | `1` | Day of the month to target when `strategy` is `calendar`. | + +Set individual options from the command line: ```bash pbm config --set lifecycle.dailyRetention=7 ``` -Or add the block to the PBM configuration file and apply the file: +You can also apply a configuration file: ```bash pbm config --file= ``` -## Example policies +For details about the configuration file and how to apply it, see [Configure PBM](../reference/config.md). -### Recommended baseline +## Example retention policies -For most deployments, start with seven daily, four weekly, and 12 monthly backups under the `rolling` strategy, paired with `purgeFailed: true`. +### Rolling retention -Seven days cover the mistake you notice within a week. Four weeks cover silent corruption that nobody caught in time. Twelve months cover audits under standards such as SOC 2, HIPAA, and PCI DSS. +The following policy keeps all completed backups for seven days, one weekly backup for four weeks, and one monthly backup for 12 months. This policy suits most deployments. ```yaml lifecycle: enabled: false - strategy: "rolling" + strategy: rolling minKeep: 1 prompt: true purgeFailed: true @@ -80,14 +138,18 @@ lifecycle: monthlyRetention: 12 ``` -### Calendar policy for an audit +Keep `enabled: false` while you review the policy. Run a dry run before you enable rotation. + +### Calendar retention -This policy keeps every backup for 14 days, the Friday backup for eight weeks, and the backup from the 15th of the month for six months: +The following policy keeps all completed backups for 14 days, targets Friday backups for eight weeks, and targets the 15th of each month for six months. ```yaml lifecycle: enabled: false - strategy: "calendar" + strategy: calendar + minKeep: 1 + prompt: true purgeFailed: false dailyRetention: 14 weeklyRetention: 8 @@ -96,23 +158,19 @@ lifecycle: monthlyDay: 15 ``` -!!! note - - Both examples start with `enabled: false`. Validate the rules with a dry run, then turn the feature on. +## Run a lifecycle rotation -## Run a rotation +Lifecycle rotation deletes backups permanently, so validate the policy first. The command uses the same connection options, environment variables, and authentication as every other PBM command. -A purge deletes data permanently, so PBM separates the decision from the action. The command uses the same connection options, environment variables, and authentication as every other PBM command. +### 1. Run a dry run -### Step 1. Validate with a dry run - -The `--dry-run` flag overrides the `enabled: false` safety switch. PBM evaluates the rules against your storage and prints a report. Nothing leaves storage: +Use `--dry-run` to see which backups PBM would keep and purge. The flag works while `lifecycle.enabled` is `false`, so you can test a policy before you turn rotation on. ```bash pbm lifecycle --dry-run ``` -Output: +The dry run deletes nothing. ```text Lifecycle Report (Dry Run: true) @@ -129,21 +187,25 @@ Backups to PURGE (2): - 2026-03-24T04:02:01Z ``` -Check that the oldest restore point you depend on appears under the backups to keep. +Check that the restore points you need appear under `Backups to KEEP`. + +### 2. Enable lifecycle rotation -### Step 2. Turn the feature on +After you verify the dry-run results, enable lifecycle rotation: ```bash pbm config --set lifecycle.enabled=true ``` -### Step 3. Run the rotation +### 3. Run the rotation + +Run the lifecycle command: ```bash pbm lifecycle ``` -With `prompt: true`, PBM prints the same report and waits for your answer: +With `lifecycle.prompt` set to `true`, PBM displays the backups selected for retention and purging, then asks for confirmation before it deletes them. ```text Are you sure you want to permanently delete the purged backups? [y/N]: y @@ -152,133 +214,160 @@ Purging backup 2026-03-18T04:02:01Z... Lifecycle rotation complete. ``` -To cancel, answer `N` or press `Ctrl+C`. A `Ctrl+C` during the deletion aborts the remaining purges. +Enter `N` or press `Ctrl+C` at the confirmation prompt to cancel the operation. If deletion has already started, `Ctrl+C` stops the remaining purge operations. -## Separate retention per storage profile +## Use lifecycle policies with storage profiles -A policy applies at one of two scopes. +You can configure lifecycle policies globally or per storage profile. -| Scope | What it covers | Command | +| Scope | Description | Command | | --- | --- | --- | -| Global | All backups, with the same rules for every backup type | `pbm lifecycle` | -| Profile | Only the backups routed to that profile | `pbm lifecycle --profile=` | +| Global | Applies the lifecycle policy to backups managed by the global configuration. | `pbm lifecycle` | +| Profile | Applies the lifecycle policy to backups routed to a specific storage profile. | `pbm lifecycle --profile=` | + +Use a storage profile when different backup sets need different retention periods. A common split keeps physical backups in one profile for a year, and logical backups in another for a few days. + +Add the `lifecycle` section to the profile configuration file, alongside the storage settings. The following file, `pbm-physical.conf`, holds the long-term policy: + +```yaml +storage: + type: s3 + s3: + region: us-east-1 + bucket: mongo-physical-backups + prefix: pbm/physical +lifecycle: + enabled: true + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 7 + weeklyRetention: 4 + monthlyRetention: 12 +``` -Use the global scope when one set of rules suits all your data. Use profiles when retention lengths differ, or when buckets in separate regions carry separate compliance rules. A common split keeps physical backups for a year and logical backups for three days. +Apply the configuration: -### Procedure +```bash +pbm profile add physical-backup pbm-physical.conf +``` -Follow these steps: -{.power-number} +A second file, `pbm-logical.conf`, holds a shorter retention period. A value of `0` turns off the weekly and monthly tiers: -1. Configure the physical profile +```yaml +storage: + type: s3 + s3: + region: us-east-1 + bucket: mongo-logical-backups + prefix: pbm/logical +lifecycle: + enabled: true + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 3 + weeklyRetention: 0 + monthlyRetention: 0 +``` - Create `pbm-physical.conf` with the storage settings and the long-term rules: +```bash +pbm profile add logical-backup pbm-logical.conf +``` - ```yaml - storage: - type: s3 - s3: - region: us-east-1 - bucket: mongo-physical-backups - prefix: pbm/physical - lifecycle: - enabled: true - strategy: rolling - minKeep: 1 - prompt: true - purgeFailed: true - dailyRetention: 7 - weeklyRetention: 4 - monthlyRetention: 12 - ``` +Use the `--profile` option to evaluate a specific profile: - ```bash - pbm profile add physical-backup pbm-physical.conf - ``` +```bash +pbm lifecycle --profile=physical-backup --dry-run +pbm lifecycle --profile=logical-backup --dry-run +``` -2. Configure the logical profile +When you name a profile, PBM evaluates the lifecycle policy configured for that profile and ignores the global configuration. - Create `pbm-logical.conf` with the short-term rules. A value of `0` turns off the weekly and monthly tiers: +See [Storage profiles](../usage/profiles.md) for information about creating and configuring PBM storage profiles. - ```yaml - storage: - type: s3 - s3: - region: us-east-1 - bucket: mongo-logical-backups - prefix: pbm/logical - lifecycle: - enabled: true - strategy: rolling - minKeep: 1 - prompt: true - purgeFailed: true - dailyRetention: 3 - weeklyRetention: 0 - monthlyRetention: 0 - ``` +## Retention of different backup types - ```bash - pbm profile add logical-backup pbm-logical.conf - ``` +PBM can manage physical, logical, and incremental backups. -3. Rotate one profile +Lifecycle management keeps each backup type in a separate retention group. A logical backup does not replace a physical backup in the same retention window, and a physical backup does not replace a logical one. - Add the `--profile` flag to evaluate or purge a single profile. PBM ignores the global configuration for that run and tags each kept backup with the tier that saved it, such as `[Daily]` or `[Weekly]`: +For example, if a weekly retention window holds both a physical and a logical backup, PBM retains one backup of each type for that window. - ```bash - pbm lifecycle --profile=physical-backup --dry-run - pbm lifecycle --profile=logical-backup --dry-run - ``` +If you need different retention periods for different backup types, use separate storage profiles and configure a lifecycle policy for each profile. + +!!! note + + Long retention periods for both physical and logical backups increase storage usage. Separate storage profiles give each backup type its own retention period. -## Automate the rotation +## Automate lifecycle rotation -A daily `cron` job keeps storage under control without manual work. First turn off the interactive prompt, which waits forever in the background, and confirm the circuit breaker: +You can run lifecycle rotation from `cron` or another scheduler. + +Before you automate the command, disable the interactive confirmation prompt. A prompt in a scheduled job waits for an answer that never arrives: ```bash pbm config --set lifecycle.prompt=false +``` + +If you use storage profiles, set `prompt: false` in the lifecycle configuration for each profile that you automate. + +Keep the `minKeep` safety setting in place: + +```bash pbm config --set lifecycle.minKeep=1 ``` -Schedule the run for off-peak hours, away from your backup jobs. The `--out json` flag produces output that a log collector can parse: +Run lifecycle rotation at a different time from your backup jobs, so that backup and retention operations do not compete for resources. The `--out json` option writes machine-readable output, which suits a log file. + +The following `cron` entry runs the global lifecycle rotation every day at 3:00 AM: ```bash -# Run the rotation every day at 3:00 AM 0 3 * * * /usr/bin/pbm lifecycle --out json >> /var/log/pbm-lifecycle-global.log 2>&1 ``` -Profiles rotate one at a time: +You can also schedule profile rotations separately: ```bash -# Long-term physical backups at 2:00 AM 0 2 * * * /usr/bin/pbm lifecycle --profile=physical-backup --out json >> /var/log/pbm-lifecycle-phys.log 2>&1 - -# Short-term logical backups at 2:30 AM 30 2 * * * /usr/bin/pbm lifecycle --profile=logical-backup --out json >> /var/log/pbm-lifecycle-logi.log 2>&1 ``` -!!! warning - - Profiles carry their own settings. Set `prompt: false` inside each profile configuration file as well, not only in the global configuration. - ## Safety checks -PBM protects recoverability during a rotation with the following guards. +PBM applies several checks while it evaluates backups for removal. -| **Situation** | **Behavior** | +| Situation | PBM behavior | | --- | --- | -| A purge would leave too few backups | The rotation aborts in full when the survivors fall below `minKeep`. | -| A backup is the base for an active PITR chain | PBM refuses the deletion and logs an `ErrBaseForPITR` warning. | -| A backup is in progress | Backups in the `starting`, `running`, or `dumpDone` state stay out of the evaluation. | -| A backup matches several rules at once | PBM flags the backup for each tier and keeps a single copy until the longest window expires. | -| A backup failed or was canceled | `purgeFailed: false` protects the backup without a time limit. `purgeFailed: true` keeps the backup for the length of the daily window, then deletes it. A failed backup never serves as a weekly or monthly anchor. | -| No backup exists on a calendar anchor date | PBM keeps the closest backup from that month. | +| A rotation would leave fewer backups than `minKeep` | PBM aborts the rotation. | +| A backup is required as the base for an active point-in-time recovery (PITR) chain | PBM does not delete the backup and reports an `ErrBaseForPITR` warning. | +| A backup is in progress | Backups in the `starting`, `running`, or `dumpDone` state are excluded from lifecycle evaluation. | +| A backup matches more than one retention rule | PBM keeps the backup until the longest applicable retention period expires. | +| A backup failed or was canceled | With `purgeFailed: false`, PBM protects it indefinitely. With `purgeFailed: true`, PBM keeps it for the `dailyRetention` period. Failed backups are not selected for weekly or monthly retention. | +| No backup exists on a calendar target date | PBM retains the closest available backup from that month. | -An aborted automated run logs the reason. Review your retention settings when this message appears: +If `minKeep` aborts an automated rotation, PBM reports the reason in its output. +```text +WARNING: This rotation would leave you with 0 backup(s), which is below +the safety threshold of 1 (minKeep). -!!! WARNING - ``` - This rotation would leave you with 0 backup(s), which is below the safety threshold of 1 (minKeep). Automated run (prompt: false) detected. Purge aborted to protect your backups. - ``` +Automated run (prompt: false) detected. Purge aborted to protect your backups. +``` + +Review the lifecycle configuration and the backups selected for retention before you run the rotation again. + +## Related topics + +- [Configure backup storage](../reference/config.md) + +- [Storage profiles](../usage/profiles.md) + +- [Delete backups](../usage/delete-backup.md) + +- [Restore a backup](../usage/restore.md) + +- [Point-in-time recovery](../features/point-in-time-recovery.md) From bf9f86a21f89211990896d7a3102c6d6b5815a2f Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 17:09:33 +0530 Subject: [PATCH 05/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 63 ++++++++++++----------- 1 file changed, 32 insertions(+), 31 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index c4330ed6..96f12f93 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -37,57 +37,58 @@ lifecycle: PBM keeps every completed backup from the last seven days, with no thinning inside that window. Take a backup every six hours and all 28 stay. Older backups move into the weekly and monthly tiers, where PBM keeps one backup per window and purges the rest. -### Rolling strategy -The `rolling` strategy is the default. +=== "Rolling strategy" -PBM measures the age of a backup from the time the rotation runs, rather than from the calendar date on the backup. Past the daily window, the timeline splits into seven-day windows for the weekly tier and 30-day windows for the monthly tier. PBM keeps the newest backup in each window. + The `rolling` strategy is the default. -This behavior helps when backups do not run at the same time every day, or when a scheduled backup is missed. PBM keeps the available backup that fits the window best, so a gap in the schedule does not break the policy. + PBM measures the age of a backup from the time the rotation runs, rather than from the calendar date on the backup. Past the daily window, the timeline splits into seven-day windows for the weekly tier and 30-day windows for the monthly tier. PBM keeps the newest backup in each window. -```yaml -lifecycle: - strategy: rolling -``` + This behavior helps when backups do not run at the same time every day, or when a scheduled backup is missed. PBM keeps the available backup that fits the window best, so a gap in the schedule does not break the policy. + + ```yaml + lifecycle: + strategy: rolling + ``` -### Calendar strategy +=== "Calendar strategy" -The `calendar` strategy targets configured days of the week and month. + The `calendar` strategy targets configured days of the week and month. -Use `weeklyDay` to specify the day of the week for weekly retention: + Use `weeklyDay` to specify the day of the week for weekly retention: -- `0` = Sunday + - `0` = Sunday -- `1` = Monday + - `1` = Monday -- `2` = Tuesday + - `2` = Tuesday -- `3` = Wednesday + - `3` = Wednesday -- `4` = Thursday + - `4` = Thursday -- `5` = Friday + - `5` = Friday -- `6` = Saturday + - `6` = Saturday -Use `monthlyDay` to specify the day of the month, from `1` to `31`. + Use `monthlyDay` to specify the day of the month, from `1` to `31`. -??? example + ??? example - ```yaml - lifecycle: - strategy: calendar - weeklyRetention: 8 - weeklyDay: 5 - monthlyRetention: 6 - monthlyDay: 15 - ``` + ```yaml + lifecycle: + strategy: calendar + weeklyRetention: 8 + weeklyDay: 5 + monthlyRetention: 6 + monthlyDay: 15 + ``` - This configuration targets Friday backups for weekly retention and backups from the 15th of the month for monthly retention. + This configuration targets Friday backups for weekly retention and backups from the 15th of the month for monthly retention. -!!! note + !!! note - A calendar policy does not require a backup on the target day. If the 15th has no backup, PBM keeps the closest available backup from that month. + A calendar policy does not require a backup on the target day. If the 15th has no backup, PBM keeps the closest available backup from that month. ## Configuration From abe0c9430de21e7d51c31910230c1c9a2753392c Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 17:11:14 +0530 Subject: [PATCH 06/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 60 +++++++++++------------ 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 96f12f93..278358ce 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -123,41 +123,41 @@ For details about the configuration file and how to apply it, see [Configure PBM ## Example retention policies -### Rolling retention +=== "Rolling retention" -The following policy keeps all completed backups for seven days, one weekly backup for four weeks, and one monthly backup for 12 months. This policy suits most deployments. + The following policy keeps all completed backups for seven days, one weekly backup for four weeks, and one monthly backup for 12 months. This policy suits most deployments. -```yaml -lifecycle: - enabled: false - strategy: rolling - minKeep: 1 - prompt: true - purgeFailed: true - dailyRetention: 7 - weeklyRetention: 4 - monthlyRetention: 12 -``` + ```yaml + lifecycle: + enabled: false + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 7 + weeklyRetention: 4 + monthlyRetention: 12 + ``` -Keep `enabled: false` while you review the policy. Run a dry run before you enable rotation. + Keep `enabled: false` while you review the policy. Run a dry run before you enable rotation. -### Calendar retention +=== "Calendar retention" -The following policy keeps all completed backups for 14 days, targets Friday backups for eight weeks, and targets the 15th of each month for six months. + The following policy keeps all completed backups for 14 days, targets Friday backups for eight weeks, and targets the 15th of each month for six months. -```yaml -lifecycle: - enabled: false - strategy: calendar - minKeep: 1 - prompt: true - purgeFailed: false - dailyRetention: 14 - weeklyRetention: 8 - weeklyDay: 5 - monthlyRetention: 6 - monthlyDay: 15 -``` + ```yaml + lifecycle: + enabled: false + strategy: calendar + minKeep: 1 + prompt: true + purgeFailed: false + dailyRetention: 14 + weeklyRetention: 8 + weeklyDay: 5 + monthlyRetention: 6 + monthlyDay: 15 + ``` ## Run a lifecycle rotation @@ -360,7 +360,7 @@ Automated run (prompt: false) detected. Purge aborted to protect your backups. Review the lifecycle configuration and the backups selected for retention before you run the rotation again. -## Related topics +## Next steps - [Configure backup storage](../reference/config.md) From 9bf07a90d62d250f66bb6e82107f735e89e3b452 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 18:00:11 +0530 Subject: [PATCH 07/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 349 ++++++++-------------- 1 file changed, 121 insertions(+), 228 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 278358ce..ea9c0c5f 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -1,12 +1,8 @@ # Backup lifecycle management -The Backup Lifecycle Management feature automates the retention and rotation of Percona Backup for MongoDB (PBM) backups. This feature allows administrators to define a **Grandfather-Father-Son (GFS)** style retention policy to automatically purge aged data while preserving specific historical recovery points for long-term compliance, disaster recovery, and cost management. +Backup lifecycle management tells Percona Backup for MongoDB (PBM) how long to keep each backup and when to remove the ones that have aged out. You define the policy once, and PBM handles the cleanup. -PBM supports two retention strategies: - -- `rolling` keeps the newest available backup in each retention window. - -- `calendar` keeps backups from configured days of the week or month. +The policy follows the Grandfather-Father-Son (GFS) retention scheme. Keep every backup for a recent period, then keep fewer as backups age. A common policy keeps every backup for seven days, one backup per week for four weeks, and one backup per month for 12 months. A lifecycle policy applies to all backups, or to a single storage profile. @@ -26,209 +22,164 @@ Three retention tiers make up a policy: Set a retention value to `0` to turn that tier off. -For example, with the following settings: +PBM keeps every completed backup inside the daily window, with no thinning. Older backups move into the weekly and monthly tiers, where PBM keeps one backup per window and purges the rest. + +## Retention strategies + +### Rolling strategy + +The `rolling` strategy is the default. PBM measures backup age from the time rotation runs, not from the calendar date. Past the daily window, the timeline splits into seven-day windows for weekly retention and 30-day windows for monthly retention. PBM keeps the newest backup in each window. + +This approach is resilient when backups do not run at the same time every day, or when a scheduled backup is missed. PBM selects the best available backup for each window. ```yaml lifecycle: - dailyRetention: 7 - weeklyRetention: 4 - monthlyRetention: 12 + strategy: rolling ``` -PBM keeps every completed backup from the last seven days, with no thinning inside that window. Take a backup every six hours and all 28 stay. Older backups move into the weekly and monthly tiers, where PBM keeps one backup per window and purges the rest. +### Calendar strategy +The `calendar` strategy targets specific days: -=== "Rolling strategy" +- `weeklyDay`: day of the week, from `0` for Sunday to `6` for Saturday. - The `rolling` strategy is the default. +- `monthlyDay`: day of the month, from `1` to `31`. - PBM measures the age of a backup from the time the rotation runs, rather than from the calendar date on the backup. Past the daily window, the timeline splits into seven-day windows for the weekly tier and 30-day windows for the monthly tier. PBM keeps the newest backup in each window. - - This behavior helps when backups do not run at the same time every day, or when a scheduled backup is missed. PBM keeps the available backup that fits the window best, so a gap in the schedule does not break the policy. +??? example "Example" ```yaml lifecycle: - strategy: rolling + strategy: calendar + weeklyRetention: 8 + weeklyDay: 5 + monthlyRetention: 6 + monthlyDay: 15 ``` -=== "Calendar strategy" - - The `calendar` strategy targets configured days of the week and month. - - Use `weeklyDay` to specify the day of the week for weekly retention: - - - `0` = Sunday - - - `1` = Monday - - - `2` = Tuesday - - - `3` = Wednesday - - - `4` = Thursday - - - `5` = Friday - - - `6` = Saturday - - Use `monthlyDay` to specify the day of the month, from `1` to `31`. + This policy keeps Friday backups for eight weeks and backups from the 15th of each month for six months. - ??? example - - ```yaml - lifecycle: - strategy: calendar - weeklyRetention: 8 - weeklyDay: 5 - monthlyRetention: 6 - monthlyDay: 15 - ``` - - This configuration targets Friday backups for weekly retention and backups from the 15th of the month for monthly retention. - - !!! note +!!! note - A calendar policy does not require a backup on the target day. If the 15th has no backup, PBM keeps the closest available backup from that month. + A calendar policy does not require a backup on the target day. If no backup exists, PBM keeps the closest available backup from that month. -## Configuration +## Configuration options Configure lifecycle management in the `lifecycle` section of the PBM configuration. | **Option** | **Type** | **Default** | **Description** | | --- | --- | --- | --- | | `lifecycle.enabled` | Boolean | `false` | Enables lifecycle rotation. | -| `lifecycle.strategy` | String | `rolling` | Retention strategy. Supported values are `rolling` and `calendar`. | -| `lifecycle.minKeep` | Integer | `1` | Minimum number of backups that must remain after a rotation. PBM aborts the rotation if the number would fall below this value. | -| `lifecycle.prompt` | Boolean | `true` | Prompts for confirmation before deleting backups. Set to `false` when you run lifecycle rotation without interactive input. | -| `lifecycle.purgeFailed` | Boolean | `false` | Controls retention of failed and canceled backups. When `false`, PBM protects them indefinitely. When `true`, PBM keeps them for the `dailyRetention` period. | -| `lifecycle.dailyRetention` | Integer | `0` | Number of days to keep every completed backup. | -| `lifecycle.weeklyRetention` | Integer | `0` | Number of weeks to retain one weekly backup. | -| `lifecycle.weeklyDay` | Integer | `0` | Day of the week to target when `strategy` is `calendar`. | -| `lifecycle.monthlyRetention` | Integer | `0` | Number of months to retain one monthly backup. | -| `lifecycle.monthlyDay` | Integer | `1` | Day of the month to target when `strategy` is `calendar`. | - -Set individual options from the command line: +| `lifecycle.strategy` | String | `rolling` | Retention strategy: `rolling` or `calendar`. | +| `lifecycle.minKeep` | Integer | `1` | Minimum backups to keep. Rotation aborts if fewer would remain. | +| `lifecycle.prompt` | Boolean | `true` | Prompts for confirmation before deletion. Set to `false` for scheduled runs. | +| `lifecycle.purgeFailed` | Boolean | `false` | Retention of failed and canceled backups. `false` keeps them indefinitely. `true` keeps them for the daily retention period. | +| `lifecycle.dailyRetention` | Integer | `0` | Days to keep all backups. | +| `lifecycle.weeklyRetention` | Integer | `0` | Weeks to keep one backup per week. | +| `lifecycle.weeklyDay` | Integer | `0` | Target day for weekly retention. Applies to the `calendar` strategy. | +| `lifecycle.monthlyRetention` | Integer | `0` | Months to keep one backup per month. | +| `lifecycle.monthlyDay` | Integer | `1` | Target day for monthly retention. Applies to the `calendar` strategy. | + +Set options from the command line: ```bash pbm config --set lifecycle.dailyRetention=7 ``` -You can also apply a configuration file: +Or apply a configuration file: ```bash pbm config --file= ``` -For details about the configuration file and how to apply it, see [Configure PBM](../reference/config.md). - -## Example retention policies - -=== "Rolling retention" - - The following policy keeps all completed backups for seven days, one weekly backup for four weeks, and one monthly backup for 12 months. This policy suits most deployments. - - ```yaml - lifecycle: - enabled: false - strategy: rolling - minKeep: 1 - prompt: true - purgeFailed: true - dailyRetention: 7 - weeklyRetention: 4 - monthlyRetention: 12 - ``` - - Keep `enabled: false` while you review the policy. Run a dry run before you enable rotation. - -=== "Calendar retention" - - The following policy keeps all completed backups for 14 days, targets Friday backups for eight weeks, and targets the 15th of each month for six months. - - ```yaml - lifecycle: - enabled: false - strategy: calendar - minKeep: 1 - prompt: true - purgeFailed: false - dailyRetention: 14 - weeklyRetention: 8 - weeklyDay: 5 - monthlyRetention: 6 - monthlyDay: 15 - ``` +## Example policies -## Run a lifecycle rotation +### Rolling retention -Lifecycle rotation deletes backups permanently, so validate the policy first. The command uses the same connection options, environment variables, and authentication as every other PBM command. +```yaml +lifecycle: + enabled: false + strategy: rolling + minKeep: 1 + prompt: true + purgeFailed: true + dailyRetention: 7 + weeklyRetention: 4 + monthlyRetention: 12 +``` -### 1. Run a dry run +This policy suits most deployments. Keep `enabled: false` while you review it, and run a dry run before you enable rotation. -Use `--dry-run` to see which backups PBM would keep and purge. The flag works while `lifecycle.enabled` is `false`, so you can test a policy before you turn rotation on. +### Calendar retention -```bash -pbm lifecycle --dry-run +```yaml +lifecycle: + enabled: false + strategy: calendar + minKeep: 1 + prompt: true + purgeFailed: false + dailyRetention: 14 + weeklyRetention: 8 + weeklyDay: 5 + monthlyRetention: 6 + monthlyDay: 15 ``` -The dry run deletes nothing. +This policy keeps backups for 14 days, targets Fridays for weekly retention, and the 15th of each month for six months. -```text -Lifecycle Report (Dry Run: true) -Enabled: false | Strategy: ROLLING | Purge Failed: true -Daily: 7 | Weekly: 4 [Auto (Newest in bucket)] | Monthly: 6 [Auto (Newest in bucket)] +## Running lifecycle rotation -Backups to KEEP (3): - - 2026-03-26T04:02:01Z - - 2026-03-22T04:02:01Z - - 2026-03-15T04:02:01Z +Lifecycle rotation deletes backups permanently. Validate the policy first. +{.power-number} -Backups to PURGE (2): - - 2026-03-25T04:02:02Z - - 2026-03-24T04:02:01Z -``` +1. Run a dry run -Check that the restore points you need appear under `Backups to KEEP`. + ```bash + pbm lifecycle --dry-run + ``` -### 2. Enable lifecycle rotation + The report shows which backups PBM would keep and purge. No deletions occur. The flag works while `lifecycle.enabled` is `false`, so you can test a policy before you enable rotation. -After you verify the dry-run results, enable lifecycle rotation: + ```text + Lifecycle Report (Dry Run: true) + Enabled: false | Strategy: ROLLING | Purge Failed: true -```bash -pbm config --set lifecycle.enabled=true -``` + Backups to KEEP (3): + - 2026-03-26T04:02:01Z + - 2026-03-22T04:02:01Z + - 2026-03-15T04:02:01Z -### 3. Run the rotation + Backups to PURGE (2): + - 2026-03-25T04:02:02Z + - 2026-03-24T04:02:01Z + ``` -Run the lifecycle command: +2. Enable rotation -```bash -pbm lifecycle -``` + ```bash + pbm config --set lifecycle.enabled=true + ``` -With `lifecycle.prompt` set to `true`, PBM displays the backups selected for retention and purging, then asks for confirmation before it deletes them. +3. Run the rotation -```text -Are you sure you want to permanently delete the purged backups? [y/N]: y -Starting deletion... -Purging backup 2026-03-18T04:02:01Z... -Lifecycle rotation complete. -``` + ```bash + pbm lifecycle + ``` -Enter `N` or press `Ctrl+C` at the confirmation prompt to cancel the operation. If deletion has already started, `Ctrl+C` stops the remaining purge operations. + With `lifecycle.prompt` set to `true`, PBM displays the selected backups and asks for confirmation before deletion. Enter `N` or press `Ctrl+C` to cancel. -## Use lifecycle policies with storage profiles +## Storage profiles -You can configure lifecycle policies globally or per storage profile. +Lifecycle policies can apply globally or per storage profile. -| Scope | Description | Command | +| **Scope** | **Description** | **Command** | | --- | --- | --- | -| Global | Applies the lifecycle policy to backups managed by the global configuration. | `pbm lifecycle` | -| Profile | Applies the lifecycle policy to backups routed to a specific storage profile. | `pbm lifecycle --profile=` | +| Global | Applies to all backups. | `pbm lifecycle` | +| Profile | Applies to backups in a specific profile. | `pbm lifecycle --profile=` | -Use a storage profile when different backup sets need different retention periods. A common split keeps physical backups in one profile for a year, and logical backups in another for a few days. +Use profiles when different backup sets need different retention. A common split keeps physical backups for the long term and logical backups for a few days. -Add the `lifecycle` section to the profile configuration file, alongside the storage settings. The following file, `pbm-physical.conf`, holds the long-term policy: +Add the `lifecycle` section to the profile configuration file, alongside the storage settings: ```yaml storage: @@ -254,121 +205,63 @@ Apply the configuration: pbm profile add physical-backup pbm-physical.conf ``` -A second file, `pbm-logical.conf`, holds a shorter retention period. A value of `0` turns off the weekly and monthly tiers: - -```yaml -storage: - type: s3 - s3: - region: us-east-1 - bucket: mongo-logical-backups - prefix: pbm/logical -lifecycle: - enabled: true - strategy: rolling - minKeep: 1 - prompt: true - purgeFailed: true - dailyRetention: 3 - weeklyRetention: 0 - monthlyRetention: 0 -``` - -```bash -pbm profile add logical-backup pbm-logical.conf -``` - -Use the `--profile` option to evaluate a specific profile: +Evaluate a specific profile: ```bash pbm lifecycle --profile=physical-backup --dry-run -pbm lifecycle --profile=logical-backup --dry-run ``` When you name a profile, PBM evaluates the lifecycle policy configured for that profile and ignores the global configuration. -See [Storage profiles](../usage/profiles.md) for information about creating and configuring PBM storage profiles. - -## Retention of different backup types +## Retention by backup type -PBM can manage physical, logical, and incremental backups. +PBM manages physical, logical, and incremental backups separately. A logical backup does not replace a physical backup in the same retention window, and a physical backup does not replace a logical one. If a weekly window holds both, PBM keeps one of each. -Lifecycle management keeps each backup type in a separate retention group. A logical backup does not replace a physical backup in the same retention window, and a physical backup does not replace a logical one. - -For example, if a weekly retention window holds both a physical and a logical backup, PBM retains one backup of each type for that window. - -If you need different retention periods for different backup types, use separate storage profiles and configure a lifecycle policy for each profile. +For different retention periods, use separate storage profiles. !!! note - Long retention periods for both physical and logical backups increase storage usage. Separate storage profiles give each backup type its own retention period. - -## Automate lifecycle rotation + Long retention for both physical and logical backups increases storage usage. Separate profiles help balance storage needs. -You can run lifecycle rotation from `cron` or another scheduler. +## Automating rotation -Before you automate the command, disable the interactive confirmation prompt. A prompt in a scheduled job waits for an answer that never arrives: +You can schedule lifecycle rotation with `cron` or another scheduler. Disable interactive prompts first: ```bash pbm config --set lifecycle.prompt=false ``` -If you use storage profiles, set `prompt: false` in the lifecycle configuration for each profile that you automate. - -Keep the `minKeep` safety setting in place: +Keep `minKeep` in place for safety: ```bash pbm config --set lifecycle.minKeep=1 ``` -Run lifecycle rotation at a different time from your backup jobs, so that backup and retention operations do not compete for resources. The `--out json` option writes machine-readable output, which suits a log file. +Run rotation at a different time than your backup jobs to avoid resource contention. Use `--out json` for machine-readable logs. -The following `cron` entry runs the global lifecycle rotation every day at 3:00 AM: +Example `cron` entry: ```bash 0 3 * * * /usr/bin/pbm lifecycle --out json >> /var/log/pbm-lifecycle-global.log 2>&1 ``` -You can also schedule profile rotations separately: - -```bash -0 2 * * * /usr/bin/pbm lifecycle --profile=physical-backup --out json >> /var/log/pbm-lifecycle-phys.log 2>&1 -30 2 * * * /usr/bin/pbm lifecycle --profile=logical-backup --out json >> /var/log/pbm-lifecycle-logi.log 2>&1 -``` - ## Safety checks -PBM applies several checks while it evaluates backups for removal. +PBM applies safeguards during rotation. -| Situation | PBM behavior | +| **Situation** | **Behavior** | | --- | --- | -| A rotation would leave fewer backups than `minKeep` | PBM aborts the rotation. | -| A backup is required as the base for an active point-in-time recovery (PITR) chain | PBM does not delete the backup and reports an `ErrBaseForPITR` warning. | -| A backup is in progress | Backups in the `starting`, `running`, or `dumpDone` state are excluded from lifecycle evaluation. | -| A backup matches more than one retention rule | PBM keeps the backup until the longest applicable retention period expires. | -| A backup failed or was canceled | With `purgeFailed: false`, PBM protects it indefinitely. With `purgeFailed: true`, PBM keeps it for the `dailyRetention` period. Failed backups are not selected for weekly or monthly retention. | -| No backup exists on a calendar target date | PBM retains the closest available backup from that month. | - -If `minKeep` aborts an automated rotation, PBM reports the reason in its output. - -```text -WARNING: This rotation would leave you with 0 backup(s), which is below -the safety threshold of 1 (minKeep). - -Automated run (prompt: false) detected. Purge aborted to protect your backups. -``` - -Review the lifecycle configuration and the backups selected for retention before you run the rotation again. +| Rotation leaves fewer than `minKeep` | Aborts rotation. | +| Backup is the base for an active point-in-time recovery (PITR) chain | Backup is kept. PBM reports `ErrBaseForPITR`. | +| Backup in progress | Excluded from evaluation. | +| Backup matches multiple rules | Retained until the longest rule expires. | +| Failed or canceled backup | Kept indefinitely with `purgeFailed: false`, or for the daily retention period with `purgeFailed: true`. | +| No backup on calendar target date | Keeps the closest available backup. | ## Next steps -- [Configure backup storage](../reference/config.md) - -- [Storage profiles](../usage/profiles.md) +- [Configure PBM](../reference/config.md) - [Delete backups](../usage/delete-backup.md) -- [Restore a backup](../usage/restore.md) - -- [Point-in-time recovery](../features/point-in-time-recovery.md) - +- [Point-in-time recovery](../features/point-in-time-recovery.md) \ No newline at end of file From cbbba503a4ae42eae4f7f5b11217c6c424821670 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 18:04:02 +0530 Subject: [PATCH 08/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index ea9c0c5f..7943c043 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -152,7 +152,7 @@ Lifecycle rotation deletes backups permanently. Validate the policy first. Backups to PURGE (2): - 2026-03-25T04:02:02Z - 2026-03-24T04:02:01Z - ``` + ``` 2. Enable rotation From a6cbb314e7a57faeaf209c28b3c45d66cd45740b Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 18:26:19 +0530 Subject: [PATCH 09/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 7943c043..a92e8960 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -1,8 +1,8 @@ # Backup lifecycle management -Backup lifecycle management tells Percona Backup for MongoDB (PBM) how long to keep each backup and when to remove the ones that have aged out. You define the policy once, and PBM handles the cleanup. +Backup lifecycle management tells Percona Backup for MongoDB (PBM) how long to retain each backup and when to remove those that have aged out. You define the policy once, and PBM handles the cleanup. -The policy follows the Grandfather-Father-Son (GFS) retention scheme. Keep every backup for a recent period, then keep fewer as backups age. A common policy keeps every backup for seven days, one backup per week for four weeks, and one backup per month for 12 months. +The policy follows the Grandfather-Father-Son (GFS) retention scheme. Keep every backup for a recent period, then keep fewer as backups age. A common policy keeps every backup for 7 days, 1 backup per week for 4 weeks, and 1 backup per month for 12 months. A lifecycle policy applies to all backups, or to a single storage profile. @@ -56,7 +56,7 @@ The `calendar` strategy targets specific days: monthlyDay: 15 ``` - This policy keeps Friday backups for eight weeks and backups from the 15th of each month for six months. + This policy retains Friday backups for 8 weeks and backups from the 15th of each month for 6 months. !!! note @@ -138,8 +138,8 @@ Lifecycle rotation deletes backups permanently. Validate the policy first. pbm lifecycle --dry-run ``` - The report shows which backups PBM would keep and purge. No deletions occur. The flag works while `lifecycle.enabled` is `false`, so you can test a policy before you enable rotation. - + The report shows which backups PBM would keep and which it would purge. No deletions occur. The flag works when `lifecycle.enabled` is `false`, so you can test a policy before enabling rotation. + ```text Lifecycle Report (Dry Run: true) Enabled: false | Strategy: ROLLING | Purge Failed: true @@ -177,7 +177,7 @@ Lifecycle policies can apply globally or per storage profile. | Global | Applies to all backups. | `pbm lifecycle` | | Profile | Applies to backups in a specific profile. | `pbm lifecycle --profile=` | -Use profiles when different backup sets need different retention. A common split keeps physical backups for the long term and logical backups for a few days. +Use profiles when different backup sets require different retention periods. A common split keeps physical backups for the long term and logical backups for a few days. Add the `lifecycle` section to the profile configuration file, alongside the storage settings: From 7a5ca74868c15574e464933468a81577aa968071 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 18:35:08 +0530 Subject: [PATCH 10/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 40 +++++++++++++---------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index a92e8960..486d8587 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -2,7 +2,7 @@ Backup lifecycle management tells Percona Backup for MongoDB (PBM) how long to retain each backup and when to remove those that have aged out. You define the policy once, and PBM handles the cleanup. -The policy follows the Grandfather-Father-Son (GFS) retention scheme. Keep every backup for a recent period, then keep fewer as backups age. A common policy keeps every backup for 7 days, 1 backup per week for 4 weeks, and 1 backup per month for 12 months. +The policy follows the Grandfather-Father-Son (GFS) retention scheme. Keep every backup for a recent period, then keep fewer as backups age. A common policy keeps every backup for seven days, one backup per week for four weeks, and one backup per month for 12 months. A lifecycle policy applies to all backups, or to a single storage profile. @@ -56,7 +56,7 @@ The `calendar` strategy targets specific days: monthlyDay: 15 ``` - This policy retains Friday backups for 8 weeks and backups from the 15th of each month for 6 months. + This policy retains Friday backups for eight weeks and backups from the 15th of each month for six months. !!! note @@ -125,7 +125,7 @@ lifecycle: monthlyDay: 15 ``` -This policy keeps backups for 14 days, targets Fridays for weekly retention, and the 15th of each month for six months. +This policy keeps all completed backups for 14 days, retains Friday backups for eight weeks, and retains backups from the 15th of each month for six months. ## Running lifecycle rotation @@ -139,20 +139,20 @@ Lifecycle rotation deletes backups permanently. Validate the policy first. ``` The report shows which backups PBM would keep and which it would purge. No deletions occur. The flag works when `lifecycle.enabled` is `false`, so you can test a policy before enabling rotation. - - ```text - Lifecycle Report (Dry Run: true) - Enabled: false | Strategy: ROLLING | Purge Failed: true - Backups to KEEP (3): - - 2026-03-26T04:02:01Z - - 2026-03-22T04:02:01Z - - 2026-03-15T04:02:01Z + ```text + Lifecycle Report (Dry Run: true) + Enabled: false | Strategy: ROLLING | Purge Failed: true - Backups to PURGE (2): - - 2026-03-25T04:02:02Z - - 2026-03-24T04:02:01Z - ``` + Backups to KEEP (3): + - 2026-03-26T04:02:01Z + - 2026-03-22T04:02:01Z + - 2026-03-15T04:02:01Z + + Backups to PURGE (2): + - 2026-03-25T04:02:02Z + - 2026-03-24T04:02:01Z + ``` 2. Enable rotation @@ -179,7 +179,7 @@ Lifecycle policies can apply globally or per storage profile. Use profiles when different backup sets require different retention periods. A common split keeps physical backups for the long term and logical backups for a few days. -Add the `lifecycle` section to the profile configuration file, alongside the storage settings: +Create a profile configuration file, `pbm-physical.conf`, with the `lifecycle` section alongside the storage settings: ```yaml storage: @@ -213,6 +213,8 @@ pbm lifecycle --profile=physical-backup --dry-run When you name a profile, PBM evaluates the lifecycle policy configured for that profile and ignores the global configuration. +For details about creating and managing profiles, see [Storage profiles](../usage/profiles.md). + ## Retention by backup type PBM manages physical, logical, and incremental backups separately. A logical backup does not replace a physical backup in the same retention window, and a physical backup does not replace a logical one. If a weekly window holds both, PBM keeps one of each. @@ -231,6 +233,8 @@ You can schedule lifecycle rotation with `cron` or another scheduler. Disable in pbm config --set lifecycle.prompt=false ``` +If you use storage profiles, set `prompt: false` in the lifecycle section of each profile configuration that you automate. + Keep `minKeep` in place for safety: ```bash @@ -255,13 +259,15 @@ PBM applies safeguards during rotation. | Backup is the base for an active point-in-time recovery (PITR) chain | Backup is kept. PBM reports `ErrBaseForPITR`. | | Backup in progress | Excluded from evaluation. | | Backup matches multiple rules | Retained until the longest rule expires. | -| Failed or canceled backup | Kept indefinitely with `purgeFailed: false`, or for the daily retention period with `purgeFailed: true`. | +| Failed or canceled backup | Kept indefinitely with `purgeFailed: false`, or for the daily retention period with `purgeFailed: true`. Failed backups are never selected as weekly or monthly anchors. | | No backup on calendar target date | Keeps the closest available backup. | ## Next steps - [Configure PBM](../reference/config.md) +- [Storage profiles](../usage/profiles.md) + - [Delete backups](../usage/delete-backup.md) - [Point-in-time recovery](../features/point-in-time-recovery.md) \ No newline at end of file From 2e12ce1bdba7df1a0a6955833e49af9665beeaa3 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 19:24:42 +0530 Subject: [PATCH 11/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 239 ++++++++++------------ 1 file changed, 113 insertions(+), 126 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 486d8587..0985796d 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -1,36 +1,45 @@ # Backup lifecycle management -Backup lifecycle management tells Percona Backup for MongoDB (PBM) how long to retain each backup and when to remove those that have aged out. You define the policy once, and PBM handles the cleanup. +Backup lifecycle management helps you control how long Percona Backup for MongoDB (PBM) keeps backups. You define a retention policy, and PBM identifies the backups that have aged out and can be removed. -The policy follows the Grandfather-Father-Son (GFS) retention scheme. Keep every backup for a recent period, then keep fewer as backups age. A common policy keeps every backup for seven days, one backup per week for four weeks, and one backup per month for 12 months. +PBM uses a Grandfather-Father-Son (GFS) retention model. You can keep every recent backup, then retain fewer recovery points as the backups age. For example, you can keep all backups for seven days, one backup per week for four weeks, and one backup per month for 12 months. -A lifecycle policy applies to all backups, or to a single storage profile. +You can define a lifecycle policy for the main storage or for an individual [storage profile](../features/multi-storage.md). !!! warning - Lifecycle rotation permanently deletes the backups selected for purging. Run `pbm lifecycle --dry-run` and review the report before you enable rotation. + Lifecycle cleanup permanently deletes the selected backups. Always run `pbm cleanup --lifecycle --dry-run` and review the report before you proceed with deletion. ## How retention works -Three retention tiers make up a policy: +A lifecycle policy can include three retention tiers: -- Daily: keeps every completed backup for the configured number of days. +* **Daily** keeps every eligible backup within the configured number of days. +* **Weekly** keeps one backup of each type in every weekly retention window. +* **Monthly** keeps one backup of each type in every monthly retention window. -- Weekly: keeps one backup for each weekly retention window. +PBM evaluates the three tiers independently. A backup is retained if it matches at least one tier. For example, the same backup can satisfy the daily, weekly, and monthly rules. -- Monthly: keeps one backup for each monthly retention window. +Set a retention value to `0` to disable that tier. -Set a retention value to `0` to turn that tier off. +!!! warning + + If you set all three retention values and `minKeep` to `0`, PBM can select every eligible backup for deletion. + +PBM evaluates backup times in UTC. In-progress backups and backups created at or after the evaluation time are not considered for deletion. -PBM keeps every completed backup inside the daily window, with no thinning. Older backups move into the weekly and monthly tiers, where PBM keeps one backup per window and purges the rest. +## Choose a retention strategy -## Retention strategies +PBM supports `rolling` and `calendar` retention strategies. Both strategies keep every eligible backup inside the daily retention period. They differ in how they select weekly and monthly backups. ### Rolling strategy -The `rolling` strategy is the default. PBM measures backup age from the time rotation runs, not from the calendar date. Past the daily window, the timeline splits into seven-day windows for weekly retention and 30-day windows for monthly retention. PBM keeps the newest backup in each window. +The `rolling` strategy is the default. It measures backup age from the time the lifecycle command runs and divides the history into fixed windows: -This approach is resilient when backups do not run at the same time every day, or when a scheduled backup is missed. PBM selects the best available backup for each window. +* Weekly retention uses seven-day windows. +* Monthly retention uses 30-day windows. + +PBM keeps the newest backup of each type in every window. This strategy works well when backup times vary or an occasional scheduled backup is missed. ```yaml lifecycle: @@ -39,13 +48,14 @@ lifecycle: ### Calendar strategy -The `calendar` strategy targets specific days: +The `calendar` strategy groups backups by calendar week and calendar month. Within each period, PBM selects the backup closest to the configured target day: -- `weeklyDay`: day of the week, from `0` for Sunday to `6` for Saturday. +* `weeklyDay` sets the target weekday. Use `0` for Sunday through `6` for Saturday. +* `monthlyDay` sets the target day of the month. Use a value from `1` through `31`. -- `monthlyDay`: day of the month, from `1` to `31`. +If no backup exists on the target day, PBM keeps the closest eligible backup in that week or month. When `monthlyDay` is later than the last day of a month, PBM uses the last day of that month as the target. -??? example "Example" +??? example "Keep Friday and mid-month backups" ```yaml lifecycle: @@ -56,67 +66,64 @@ The `calendar` strategy targets specific days: monthlyDay: 15 ``` - This policy retains Friday backups for eight weeks and backups from the 15th of each month for six months. - -!!! note - - A calendar policy does not require a backup on the target day. If no backup exists, PBM keeps the closest available backup from that month. + This policy keeps one backup of each type closest to Friday in every retained week and one backup of each type closest to the 15th in every retained month. ## Configuration options -Configure lifecycle management in the `lifecycle` section of the PBM configuration. +Define lifecycle settings in the `lifecycle` section of the [PBM configuration](../reference/config.md). -| **Option** | **Type** | **Default** | **Description** | +| Option | Type | Default | Description | | --- | --- | --- | --- | -| `lifecycle.enabled` | Boolean | `false` | Enables lifecycle rotation. | -| `lifecycle.strategy` | String | `rolling` | Retention strategy: `rolling` or `calendar`. | -| `lifecycle.minKeep` | Integer | `1` | Minimum backups to keep. Rotation aborts if fewer would remain. | -| `lifecycle.prompt` | Boolean | `true` | Prompts for confirmation before deletion. Set to `false` for scheduled runs. | -| `lifecycle.purgeFailed` | Boolean | `false` | Retention of failed and canceled backups. `false` keeps them indefinitely. `true` keeps them for the daily retention period. | -| `lifecycle.dailyRetention` | Integer | `0` | Days to keep all backups. | -| `lifecycle.weeklyRetention` | Integer | `0` | Weeks to keep one backup per week. | -| `lifecycle.weeklyDay` | Integer | `0` | Target day for weekly retention. Applies to the `calendar` strategy. | -| `lifecycle.monthlyRetention` | Integer | `0` | Months to keep one backup per month. | -| `lifecycle.monthlyDay` | Integer | `1` | Target day for monthly retention. Applies to the `calendar` strategy. | - -Set options from the command line: - -```bash -pbm config --set lifecycle.dailyRetention=7 +| `lifecycle.enabled` | Boolean | `false` | Enables lifecycle policy evaluation and cleanup. When disabled, PBM keeps all backups. | +| `lifecycle.strategy` | String | `rolling` | Sets the retention strategy. Supported values are `rolling` and `calendar`. | +| `lifecycle.minKeep` | Integer | `1` | Sets the minimum number of completed, successful restore points that must remain. PBM aborts the cleanup if it would retain fewer restore points. Set to `0` to disable this safeguard. | +| `lifecycle.purgeFailed` | Boolean | `false` | Controls the retention of failed and canceled backups. When `false`, PBM keeps them. When `true`, PBM keeps them only during the daily retention period. | +| `lifecycle.dailyRetention` | Integer | `0` | Sets the number of days to keep every eligible backup. | +| `lifecycle.weeklyRetention` | Integer | `0` | Sets the number of weeks for which PBM keeps one backup of each type per week. | +| `lifecycle.weeklyDay` | Integer | `0` | Sets the target weekday for the `calendar` strategy. Use `0` for Sunday through `6` for Saturday. | +| `lifecycle.monthlyRetention` | Integer | `0` | Sets the number of months for which PBM keeps one backup of each type per month. | +| `lifecycle.monthlyDay` | Integer | `1` | Sets the target day of the month for the `calendar` strategy. Use a value from `1` through `31`. | + +You can set an individual option from the command line: + +```{.bash data-prompt="$"} +$ pbm config --set lifecycle.dailyRetention=7 ``` -Or apply a configuration file: +To apply several settings together, add the `lifecycle` section to a configuration file and apply the file: -```bash -pbm config --file= +```{.bash data-prompt="$"} +$ pbm config --file --wait ``` ## Example policies ### Rolling retention +The following policy keeps all eligible backups for seven days, one backup of each type per week for four weeks, and one backup of each type per 30-day window for 12 months: + ```yaml lifecycle: - enabled: false + enabled: true strategy: rolling minKeep: 1 - prompt: true purgeFailed: true dailyRetention: 7 weeklyRetention: 4 monthlyRetention: 12 ``` -This policy suits most deployments. Keep `enabled: false` while you review it, and run a dry run before you enable rotation. +With `purgeFailed: true`, failed and canceled backups are kept during the seven-day daily retention period and become eligible for deletion after that period. ### Calendar retention +The following policy keeps all eligible backups for 14 days, one backup of each type closest to Friday for eight calendar weeks, and one backup of each type closest to the 15th for six calendar months: + ```yaml lifecycle: - enabled: false + enabled: true strategy: calendar minKeep: 1 - prompt: true purgeFailed: false dailyRetention: 14 weeklyRetention: 8 @@ -125,61 +132,45 @@ lifecycle: monthlyDay: 15 ``` -This policy keeps all completed backups for 14 days, retains Friday backups for eight weeks, and retains backups from the 15th of each month for six months. +## Preview and run lifecycle cleanup -## Running lifecycle rotation +Configure the policy and enable it before you run a dry run. When `lifecycle.enabled` is `false`, PBM reports all backups as retained and does not calculate deletion candidates. -Lifecycle rotation deletes backups permanently. Validate the policy first. {.power-number} -1. Run a dry run +1. Enable the policy: - ```bash - pbm lifecycle --dry-run + ```{.bash data-prompt="$"} + $ pbm config --set lifecycle.enabled=true --wait ``` - The report shows which backups PBM would keep and which it would purge. No deletions occur. The flag works when `lifecycle.enabled` is `false`, so you can test a policy before enabling rotation. - - ```text - Lifecycle Report (Dry Run: true) - Enabled: false | Strategy: ROLLING | Purge Failed: true +2. Preview the result: - Backups to KEEP (3): - - 2026-03-26T04:02:01Z - - 2026-03-22T04:02:01Z - - 2026-03-15T04:02:01Z - - Backups to PURGE (2): - - 2026-03-25T04:02:02Z - - 2026-03-24T04:02:01Z + ```{.bash data-prompt="$"} + $ pbm cleanup --lifecycle --dry-run ``` -2. Enable rotation - - ```bash - pbm config --set lifecycle.enabled=true - ``` + PBM reports the backups it would keep and purge without deleting any data. Review the **Backups to PURGE** list carefully. -3. Run the rotation +3. Run the cleanup: - ```bash - pbm lifecycle + ```{.bash data-prompt="$"} + $ pbm cleanup --lifecycle --wait ``` - With `lifecycle.prompt` set to `true`, PBM displays the selected backups and asks for confirmation before deletion. Enter `N` or press `Ctrl+C` to cancel. + PBM displays the lifecycle report and asks you to confirm the deletion. Enter `N` or press `Ctrl+C` at the confirmation prompt to cancel. + + The `--wait` flag keeps the command attached until the cleanup finishes. Without it, PBM starts the cleanup and returns control to the shell. -## Storage profiles +!!! note -Lifecycle policies can apply globally or per storage profile. + Use `--yes` to skip the confirmation prompt only after you have reviewed a dry run. This flag is required for unattended cleanup. -| **Scope** | **Description** | **Command** | -| --- | --- | --- | -| Global | Applies to all backups. | `pbm lifecycle` | -| Profile | Applies to backups in a specific profile. | `pbm lifecycle --profile=` | +## Apply a policy to a storage profile -Use profiles when different backup sets require different retention periods. A common split keeps physical backups for the long term and logical backups for a few days. +The lifecycle policy in the main PBM configuration applies only to backups in the main storage. A policy in a storage profile applies only to backups created in that profile. -Create a profile configuration file, `pbm-physical.conf`, with the `lifecycle` section alongside the storage settings: +For example, create `pbm-physical.conf` with the storage and lifecycle settings for the profile: ```yaml storage: @@ -188,86 +179,82 @@ storage: region: us-east-1 bucket: mongo-physical-backups prefix: pbm/physical + lifecycle: enabled: true strategy: rolling minKeep: 1 - prompt: true purgeFailed: true dailyRetention: 7 weeklyRetention: 4 monthlyRetention: 12 ``` -Apply the configuration: +Add the profile: -```bash -pbm profile add physical-backup pbm-physical.conf +```{.bash data-prompt="$"} +$ pbm profile add physical-backup pbm-physical.conf --wait ``` -Evaluate a specific profile: +Preview the policy for this profile: -```bash -pbm lifecycle --profile=physical-backup --dry-run +```{.bash data-prompt="$"} +$ pbm cleanup --lifecycle --profile=physical-backup --dry-run ``` -When you name a profile, PBM evaluates the lifecycle policy configured for that profile and ignores the global configuration. - -For details about creating and managing profiles, see [Storage profiles](../usage/profiles.md). +Run the cleanup after reviewing the report: -## Retention by backup type +```{.bash data-prompt="$"} +$ pbm cleanup --lifecycle --profile=physical-backup --wait +``` -PBM manages physical, logical, and incremental backups separately. A logical backup does not replace a physical backup in the same retention window, and a physical backup does not replace a logical one. If a weekly window holds both, PBM keeps one of each. +When you specify `--profile`, PBM uses the lifecycle policy from that profile and evaluates only its backups. Without `--profile`, PBM uses the main configuration and evaluates backups in the main storage. -For different retention periods, use separate storage profiles. +For details about creating and managing storage profiles, see [Multiple storages for backups](../features/multi-storage.md). -!!! note +## Retention by backup type - Long retention for both physical and logical backups increases storage usage. Separate profiles help balance storage needs. +For weekly and monthly retention, PBM evaluates logical, physical, and incremental backups separately. One backup type cannot replace another as the retained backup for a window. If a weekly window contains eligible logical and physical backups, PBM keeps one of each type. -## Automating rotation +The same retention values apply to all backup types in a given storage. To use different retention periods, send the backup types to separate storage profiles and define a lifecycle policy in each profile. -You can schedule lifecycle rotation with `cron` or another scheduler. Disable interactive prompts first: +PBM also preserves incremental backup dependencies. If any backup in an incremental chain must be retained, PBM keeps the complete chain required to restore it. -```bash -pbm config --set lifecycle.prompt=false -``` +## Automate lifecycle cleanup -If you use storage profiles, set `prompt: false` in the lifecycle section of each profile configuration that you automate. +You can schedule lifecycle cleanup with `cron` or another scheduler. Use `--yes` so the command does not wait for confirmation, and keep `minKeep` enabled as a safeguard. -Keep `minKeep` in place for safety: +Run lifecycle cleanup at a different time from scheduled backups. The following example evaluates the main storage every day at 03:00. It writes JSON output to one log file and progress messages or errors to another: ```bash -pbm config --set lifecycle.minKeep=1 +0 3 * * * /usr/bin/pbm cleanup --lifecycle --yes --wait --out=json >> /var/log/pbm-lifecycle.jsonl 2>> /var/log/pbm-lifecycle.err ``` -Run rotation at a different time than your backup jobs to avoid resource contention. Use `--out json` for machine-readable logs. - -Example `cron` entry: +To automate cleanup for a storage profile, include `--profile=`: ```bash -0 3 * * * /usr/bin/pbm lifecycle --out json >> /var/log/pbm-lifecycle-global.log 2>&1 +0 3 * * * /usr/bin/pbm cleanup --lifecycle --profile=physical-backup --yes --wait --out=json >> /var/log/pbm-lifecycle-physical.jsonl 2>> /var/log/pbm-lifecycle-physical.err ``` -## Safety checks +## Cleanup safeguards -PBM applies safeguards during rotation. +PBM applies the following safeguards when it evaluates and deletes backups: -| **Situation** | **Behavior** | +| Situation | PBM behavior | | --- | --- | -| Rotation leaves fewer than `minKeep` | Aborts rotation. | -| Backup is the base for an active point-in-time recovery (PITR) chain | Backup is kept. PBM reports `ErrBaseForPITR`. | -| Backup in progress | Excluded from evaluation. | -| Backup matches multiple rules | Retained until the longest rule expires. | -| Failed or canceled backup | Kept indefinitely with `purgeFailed: false`, or for the daily retention period with `purgeFailed: true`. Failed backups are never selected as weekly or monthly anchors. | -| No backup on calendar target date | Keeps the closest available backup. | +| Lifecycle management is disabled | Keeps all backups and does not produce deletion targets. | +| Cleanup would retain fewer successful restore points than `minKeep` | Aborts the cleanup. | +| A backup is required as the base for an active [point-in-time recovery](../features/point-in-time-recovery.md) timeline | Keeps the backup and reports it as a PITR base snapshot. | +| A retained backup belongs to an incremental chain | Keeps the complete chain required to restore that backup. | +| An incremental chain is incomplete or invalid | Keeps the affected chain members. | +| A backup is in progress | Excludes it from lifecycle evaluation. | +| A selective backup is present | Excludes it from lifecycle cleanup and keeps it. | +| A backup matches more than one retention rule | Keeps it until it no longer matches any rule. | +| A backup failed or was canceled | Keeps it when `purgeFailed` is `false`. When `purgeFailed` is `true`, keeps it only within the daily retention period. Failed and canceled backups are not selected for weekly or monthly retention. | ## Next steps -- [Configure PBM](../reference/config.md) - -- [Storage profiles](../usage/profiles.md) - -- [Delete backups](../usage/delete-backup.md) - -- [Point-in-time recovery](../features/point-in-time-recovery.md) \ No newline at end of file +* [Configure PBM](../reference/config.md) +* [Multiple storages for backups](../features/multi-storage.md) +* [Delete backups](../usage/delete-backup.md) +* [Point-in-time recovery](../features/point-in-time-recovery.md) From e309b88d5ce6a0c71df8c938ac78c3a155b23d63 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 19:30:07 +0530 Subject: [PATCH 12/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 0985796d..4722c14a 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -86,14 +86,14 @@ Define lifecycle settings in the `lifecycle` section of the [PBM configuration]( You can set an individual option from the command line: -```{.bash data-prompt="$"} -$ pbm config --set lifecycle.dailyRetention=7 +```bash +pbm config --set lifecycle.dailyRetention=7 ``` To apply several settings together, add the `lifecycle` section to a configuration file and apply the file: -```{.bash data-prompt="$"} -$ pbm config --file --wait +```bash +pbm config --file --wait ``` ## Example policies From f49d24ef8f7735173c93dc275cfd84dd99acb764 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 19:36:58 +0530 Subject: [PATCH 13/16] Formatting fixes --- docs/usage/backup-lifecycle-management.md | 39 +++++++++++------------ 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 4722c14a..7c53f6a7 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -23,14 +23,13 @@ PBM evaluates the three tiers independently. A backup is retained if it matches Set a retention value to `0` to disable that tier. !!! warning + - If you set all three retention values and `minKeep` to `0`, PBM can select every eligible backup for deletion. - If you set all three retention values and `minKeep` to `0`, PBM can select every eligible backup for deletion. - -PBM evaluates backup times in UTC. In-progress backups and backups created at or after the evaluation time are not considered for deletion. + - PBM evaluates backup times in UTC. In-progress backups and backups created at or after the evaluation time are not considered for deletion. ## Choose a retention strategy -PBM supports `rolling` and `calendar` retention strategies. Both strategies keep every eligible backup inside the daily retention period. They differ in how they select weekly and monthly backups. +PBM supports `rolling` and `calendar` retention strategies. ### Rolling strategy @@ -90,7 +89,7 @@ You can set an individual option from the command line: pbm config --set lifecycle.dailyRetention=7 ``` -To apply several settings together, add the `lifecycle` section to a configuration file and apply the file: +To apply several settings together, add the `lifecycle` section to the configuration file: ```bash pbm config --file --wait @@ -135,26 +134,25 @@ lifecycle: ## Preview and run lifecycle cleanup Configure the policy and enable it before you run a dry run. When `lifecycle.enabled` is `false`, PBM reports all backups as retained and does not calculate deletion candidates. - {.power-number} 1. Enable the policy: - ```{.bash data-prompt="$"} - $ pbm config --set lifecycle.enabled=true --wait + ```bash + pbm config --set lifecycle.enabled=true --wait ``` 2. Preview the result: - ```{.bash data-prompt="$"} - $ pbm cleanup --lifecycle --dry-run + ```bash + pbm cleanup --lifecycle --dry-run ``` PBM reports the backups it would keep and purge without deleting any data. Review the **Backups to PURGE** list carefully. 3. Run the cleanup: - ```{.bash data-prompt="$"} + ```bash $ pbm cleanup --lifecycle --wait ``` @@ -162,9 +160,8 @@ Configure the policy and enable it before you run a dry run. When `lifecycle.ena The `--wait` flag keeps the command attached until the cleanup finishes. Without it, PBM starts the cleanup and returns control to the shell. -!!! note - - Use `--yes` to skip the confirmation prompt only after you have reviewed a dry run. This flag is required for unattended cleanup. + !!! note + Use `--yes` to skip the confirmation prompt only after you have reviewed a dry run. This flag is required for unattended cleanup. ## Apply a policy to a storage profile @@ -192,20 +189,20 @@ lifecycle: Add the profile: -```{.bash data-prompt="$"} -$ pbm profile add physical-backup pbm-physical.conf --wait +```bash +pbm profile add physical-backup pbm-physical.conf --wait ``` Preview the policy for this profile: -```{.bash data-prompt="$"} -$ pbm cleanup --lifecycle --profile=physical-backup --dry-run +```bash +pbm cleanup --lifecycle --profile=physical-backup --dry-run ``` Run the cleanup after reviewing the report: -```{.bash data-prompt="$"} -$ pbm cleanup --lifecycle --profile=physical-backup --wait +```bash +pbm cleanup --lifecycle --profile=physical-backup --wait ``` When you specify `--profile`, PBM uses the lifecycle policy from that profile and evaluates only its backups. Without `--profile`, PBM uses the main configuration and evaluates backups in the main storage. @@ -240,7 +237,7 @@ To automate cleanup for a storage profile, include `--profile=`: PBM applies the following safeguards when it evaluates and deletes backups: -| Situation | PBM behavior | +| **Situation** | **PBM behavior** | | --- | --- | | Lifecycle management is disabled | Keeps all backups and does not produce deletion targets. | | Cleanup would retain fewer successful restore points than `minKeep` | Aborts the cleanup. | From 32bf1e53a3b0b188ddad35db06004f40149126a8 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 19:44:39 +0530 Subject: [PATCH 14/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 7c53f6a7..739b476c 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -153,7 +153,7 @@ Configure the policy and enable it before you run a dry run. When `lifecycle.ena 3. Run the cleanup: ```bash - $ pbm cleanup --lifecycle --wait + pbm cleanup --lifecycle --wait ``` PBM displays the lifecycle report and asks you to confirm the deletion. Enter `N` or press `Ctrl+C` at the confirmation prompt to cancel. From 7f69bead9212f9fa3018dd7dd87c6dc67e815e95 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 19:58:54 +0530 Subject: [PATCH 15/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 739b476c..3093bae3 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -2,7 +2,7 @@ Backup lifecycle management helps you control how long Percona Backup for MongoDB (PBM) keeps backups. You define a retention policy, and PBM identifies the backups that have aged out and can be removed. -PBM uses a Grandfather-Father-Son (GFS) retention model. You can keep every recent backup, then retain fewer recovery points as the backups age. For example, you can keep all backups for seven days, one backup per week for four weeks, and one backup per month for 12 months. +PBM uses a [Grandfather-Father-Son (GFS) retention model :octicons-link-external-16:](https://en.wikipedia.org/wiki/Backup_rotation_scheme#Grandfather-father-son){:target="_blank"}. You can keep every recent backup, then retain fewer recovery points as the backups age. For example, you can keep all backups for seven days, one backup per week for four weeks, and one backup per month for 12 months. You can define a lifecycle policy for the main storage or for an individual [storage profile](../features/multi-storage.md). From 2f2709136f691c28a4f515536e3b4445cebc05b2 Mon Sep 17 00:00:00 2001 From: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com> Date: Tue, 22 Sep 2026 19:59:33 +0530 Subject: [PATCH 16/16] Update backup-lifecycle-management.md --- docs/usage/backup-lifecycle-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/usage/backup-lifecycle-management.md b/docs/usage/backup-lifecycle-management.md index 3093bae3..af665baa 100644 --- a/docs/usage/backup-lifecycle-management.md +++ b/docs/usage/backup-lifecycle-management.md @@ -254,4 +254,4 @@ PBM applies the following safeguards when it evaluates and deletes backups: * [Configure PBM](../reference/config.md) * [Multiple storages for backups](../features/multi-storage.md) * [Delete backups](../usage/delete-backup.md) -* [Point-in-time recovery](../features/point-in-time-recovery.md) +* [Point-in-time recovery](../features/point-in-time-recovery.md) \ No newline at end of file