8000 Improved Handling of `DAYS_TO_RETAIN` in Backup Script by a-thomas-22 · Pull Request #938 · zalando/spilo · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Improved Handling of DAYS_TO_RETAIN in Backup Script #938

New issue < 8000 button aria-label="Close dialog" data-close-dialog="" type="button" data-view-component="true" class="Link--muted btn-link position-absolute p-4 right-0">

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

a-thomas-22
Copy link

Description:

This PR focuses on the refinement and enhancement of the DAYS_TO_RETAIN logic within the backup script. The primar 8000 y objective is to establish clearer, more explicit behavior while ensuring backwards compatibility for any deployments that rely on existing behaviors.

Key Changes:

  1. Explicit DAYS_TO_RETAIN Handling:

    • The way the script determines the value of DAYS_TO_RETAIN has been made more explicit. If not set externally, it falls back to the value of BACKUP_NUM_TO_RETAIN.
    • Log messages have been introduced to notify when DAYS_TO_RETAIN is sourced from BACKUP_NUM_TO_RETAIN, ensuring transparency in its determination.
  2. Improved Backup Deletion Logic:

    • The logic which determines which backups are old enough for deletion based on DAYS_TO_RETAIN has been refined for clarity, accompanied by more descriptive log messages.
  3. Backwards Compatibility:

    • For deployments that might be relying on the previous behavior where BACKUP_NUM_TO_RETAIN was implicitly used, this fallback mechanism remains intact. This ensures that the script won't break or change behavior unexpectedly for existing setups.
    • Newer deployments or those that explicitly set DAYS_TO_RETAIN will benefit from the clearer, more descriptive behavior and logging.

Reason for Change:

The primary reason for this change is to enhance clarity and predictability around backup retention durations. Fixes #937

@a-thomas-22 a-thomas-22 changed the title Improved Handling of DAYS_TO_RETAIN in Backup Script Improved Handling of DAYS_TO_RETAIN in Backup Script Oct 16, 2023
@a-thomas-22
Copy link
Author
a-thomas-22 commented Jun 7, 2024

I made a sidecar workaround for kubernetes until a PR to fix is made for those of us having this issue
https://github.com/a-thomas-22/wal-g-pruner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Backups not being deleted as expected
1 participant
0