Skip to content

fix(infra): pgBackRest block incremental + prod Postgres data-volume sizing - #215

Merged
alex-struk merged 2 commits into
developfrom
fix/pgbackrest-block-incremental
Jun 29, 2026
Merged

fix(infra): pgBackRest block incremental + prod Postgres data-volume sizing#215
alex-struk merged 2 commits into
developfrom
fix/pgbackrest-block-incremental

Conversation

@alex-struk

Copy link
Copy Markdown
Collaborator

Context

Prod outage (2026-06-29): the app-pg data volume filled to 100% and Postgres crashed, taking down backend-services and temporal-worker. Root cause chain:

  • The high-churn ocr_results table (309MB, mostly TOAST) is appended to constantly by document processing.
  • Without block incremental, pgBackRest re-copies the entire changed file segment, so each hourly incremental backed up ~256MB.
  • That filled the 10Gi backup repo → archive-push failed with "No space left on device" → WAL archiving stalled → Postgres stopped recycling WAL → pg_wal grew to 1.1G → filled the 1.5Gi pgdata → crash.

Change

Enable block incremental (repo1-block=y) + bundling (repo1-bundle=y, required by block) on both the app and temporal PostgresCluster manifests. Block incremental backs up only the changed blocks within a file instead of the whole changed segment, collapsing those 256MB incrementals to a few MB and keeping the repo from filling.

pgBackRest 2.56 is running in-cluster (block incremental needs 2.46+).

Incident recovery already performed live (this PR codifies the durable part)

During the outage I:

  1. Expanded app-pg pgdata 1.5Gi → 5Gi (restored service; codified separately in PR fix(infra): pin prod app-pg data volume to 5Gi #214).
  2. Enabled repo1-block/repo1-bundle live on app-pg.
  3. Expired old backups (kept the newest full) — freed the repo from 100% → 32%.
  4. Took a fresh full backup in block format.

Result: WAL archiving resumed (archived_count climbing, failures stopped), pg_wal drained 1.5G → 258M, pgdata back to 15%, all app pods healthy.

This PR ensures a redeploy doesn't revert the block/bundle setting (it was a live oc change). It applies to all instances — block incremental is a safe, forward-only format improvement.

Validation

oc kustomize of base shows both clusters with block=y bundle=y.

🤖 Generated with Claude Code

alex-struk and others added 2 commits June 29, 2026 09:21
…ters

A prod outage occurred when WAL filled the app-pg data volume: the pgBackRest
repo filled with huge hourly incrementals (~256MB each, re-copying whole changed
file segments of the high-churn ocr_results table), which stalled WAL archiving,
so Postgres stopped recycling WAL until pgdata hit 100% and the DB crashed.

Enable block incremental (repo1-block) + bundling (repo1-bundle, required) on
both the app and temporal Postgres clusters. Block incremental backs up only the
changed blocks within a file instead of the whole file segment, which collapses
those 256MB incrementals to a few MB and keeps the repo from filling.

These were applied live during incident recovery; this codifies them so a
redeploy does not revert the change. (pgBackRest 2.56 in cluster; needs 2.46+.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The prod app Postgres data volume was expanded in-place from 1.5Gi to 5Gi after
pg_wal accumulation filled the original volume and crashed the database (prod
outage). The base manifest still requests 1.5Gi, so the Crunchy operator would
emit the recurring "field can not be less than previous value" reconcile error.

Pin app-pg pgdata to 5Gi via the prod-resources component (same pattern as
temporal-pg). base stays 1.5Gi for ephemeral/test instances.

Note: this only codifies the storage size. The underlying cause of the WAL
growth is the pgBackRest backup repo (repo1) being full, which blocks WAL
archiving — that must be addressed separately or the volume will refill.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@alex-struk alex-struk changed the title fix(infra): enable pgBackRest block incremental on both Postgres clusters fix(infra): pgBackRest block incremental + prod Postgres data-volume sizing Jun 29, 2026
@alex-struk
alex-struk marked this pull request as ready for review June 29, 2026 18:04
@alex-struk
alex-struk merged commit 2d12db9 into develop Jun 29, 2026
9 checks passed
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.

2 participants