Skip to content

Conversation

@sunu
Copy link
Member

@sunu sunu commented Mar 24, 2025

Related to #181 (comment)

Disabling backups is only an option if using PGO >= 5.7.0

Along with disabling the backups, we can also set some Postgres settings to keep the storage consumed by WAL files in check. Here's an example:

postgrescluster:
  backupEnabled: false
  instances:
  - name: eoapi
    replicas: 1
    dataVolumeClaimSpec:
      accessModes:
      - "ReadWriteOnce"
      resources:
        requests:
          storage: "5Gi"
          cpu: "0.5"
          memory: "512Mi"
  patroni:
    dynamicConfiguration:
      postgresql:
        parameters:
          max_wal_size: "64MB"
          min_wal_size: "32MB"
          wal_keep_size: "64MB"
          checkpoint_timeout: "1min"

@sunu sunu force-pushed the disable-backups branch from 071e20e to 44f5ff0 Compare March 24, 2025 10:31
Comment on lines 176 to 182
# backupsEnabled sets whether pgBackRest backups are enabled.
# This is enabled by default.
# Disabling backups is only supported on CrunchyData Postgres Operator v5.7.0 and above.
# If enabled, please carefully review the pgBackRest config below.
# Check out CrunchyData's Postgres Operator docs for more info:
# https://access.crunchydata.com/documentation/postgres-operator/v5/tutorials/backups-disaster-recovery/backups
backupsEnabled: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this default to false until we can recommend a more robust default configuration for pgBackrest?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ividito Yeah, that was my first instinct too. But if the default is false, we could break existing setups where someone upgrades eoapi without also updating PGO. The bigger risk is that users with a working backup config might upgrade to the latest chart and miss this new flag -- suddenly their working backup mechanism will be silently ignored.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think at the moment we can still be a bit aggressive on introducing "breaking changes". I would put is as false and make sure in the next release notes we mention this new flag.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, happy to make the change if we think breaking changes are ok for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ividito @pantierra - updated the PR. Can I get another round of review before we merge please?

Copy link
Contributor

@pantierra pantierra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@pantierra pantierra merged commit 8628642 into main Apr 3, 2025
2 checks passed
@pantierra pantierra deleted the disable-backups branch April 3, 2025 08:12
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.

4 participants