perf(grafana-db): raise archive_timeout to 30min on gf-pg

A WAL segment is a fixed 16 MiB file. archive_timeout forces a segment
switch on a timer so the archive never trails reality by more than that
interval, and the switched-out segment is written and archived at its full
16 MiB no matter how few bytes of real WAL it holds. CNPG defaults this to
5min, which permits up to 288 segments/day = 4.6 GB/day per cluster.

Measured on gf-pg: the database is 21 MB and generates 4.5 MB/day of actual
WAL, while its RBD volume takes 211 MB/hour -- against 192 MB/hour predicted
from 12 switches of 16 MiB. Essentially every byte written to this volume is
padding, roughly 1100x amplification.

This resolves an anomaly that has been open since the start of the endurance
work: gf-pg appeared to write gigabytes per day for a 21 MB database, and
neither WAL volume nor data changes could account for it. Segment padding
does, exactly.

Applied to gf-pg alone as a staged rollout. It is the lowest-risk cluster
and gives the cleanest signal -- its real WAL is small enough that any change
in volume is unambiguously attributable to this parameter. The same default
affects all seven clusters and is worth an estimated ~24 GB/day of logical
writes fleet-wide, but that only goes ahead once this one is verified.

The cost is RPO. On total loss of the cluster, up to 30min of Grafana state
becomes unrecoverable instead of 5min. That state is dashboards, annotations
and preferences, changing at ~4.5 MB/day, so the window is nearly always
empty. Clusters holding credentials or job state get evaluated separately
rather than inheriting this value by default.

archive_timeout is in CNPG's GlobalDefaultSettings, not its
FixedConfigurationParameters, so it is user-overridable -- verified against
pkg/postgres/configuration.go rather than assumed.

Context: drive-endurance work on three QLC NVMe OSDs at 81-87% wear.

.woodpecker/deploy-infrastructure.yml

@@ -13,7 +13,7 @@ when:
 
 steps:
   - name: validate-secrets
-    image: alpine:3.24.1
+    image: alpine:3.21
     environment:
       TF_VAR_proxmox_api_url:
         from_secret: proxmox_api_url

kubernetes/apps/authentik/cluster.yaml

@@ -67,20 +67,6 @@ spec:
       # and slower than the lz4/zstd this build also accepts). Compresses the
       # full-page images that dominate WAL volume after each checkpoint.
       wal_compression: "zstd"
-      # A WAL segment is a fixed 16 MiB file, and archive_timeout forces a switch
-      # on a timer -- the segment is then written and archived at its full size
-      # no matter how little real WAL it holds. CNPG defaults to 5min, i.e. up
-      # to 288 segments/day = 3.2 GB/day here, most of it padding.
-      #
-      # 15min, NOT the 30min used elsewhere in this rollout. This cluster holds
-      # credentials, sessions and enrolment state, so its RPO is worth more than
-      # the difference: 30min would save a further 0.3 GB/day, which does not
-      # justify doubling the worst-case loss window on this data.
-      #
-      # It does carry a synchronous standby (instances: 2), so the realistic
-      # exposure is losing both instances, not one -- but the conservative value
-      # is cheap here and the aggressive one buys almost nothing.
-      archive_timeout: "15min"
     # Async replication makes CNPG switchover slow because the standby has
     # to chase missing WAL via barman-cloud and replay queued records
     # before it can promote. With one synchronous standby, the standby is

kubernetes/apps/home-assistant/deployment.yaml

@@ -84,7 +84,7 @@ spec:
           env:
             - name: DB_URI
               valueFrom:
-                secretKeyRef: {name: ha-pg-app, key: fqdn-uri}
+                secretKeyRef: { name: ha-pg-app, key: fqdn-uri }
           volumeMounts:
             - name: config
               mountPath: /config
@@ -96,7 +96,7 @@ spec:
               memory: 32Mi
       containers:
         - name: home-assistant
-          image: ghcr.io/home-assistant/home-assistant:2026.8.3 # {"$imagepolicy": "flux-system:home-assistant"}
+          image: ghcr.io/home-assistant/home-assistant:2026.8.2 # {"$imagepolicy": "flux-system:home-assistant"}
           env:
             - name: TZ
               value: Europe/Berlin

kubernetes/apps/home-assistant/ha-pg-cluster.yaml

@@ -86,26 +86,8 @@ spec:
       # inserts scattered across pages, so full-page writes after each
       # checkpoint dominate WAL volume; compression cuts that directly.
       #
-      # Full-page images really are ~62% of WAL here: 61.9% measured as a
-      # steady-state delta over one checkpoint cycle, against 62.4% lifetime.
-      #
-      # But switching pglz -> zstd changed NOTHING. Measured by
-      # pg_current_wal_lsn advance over 20min windows: 4911 and 4976 MB/day
-      # before, 5002 MB/day after.
-      #
-      # The reason is that `wal_compression: "on"` was never "no compression" --
-      # it is pglz, which was already compressing these page images. zstd only
-      # changes the ratio, and on recorder pages that margin is too small to
-      # measure. The original framing of this change (that the clusters "were
-      # not getting compression") was wrong; they were.
-      #
-      # Note the 62% figure is an upper bound: it is computed as
-      # wal_fpi * 8192 / wal_bytes, which assumes uncompressed 8 KiB pages. With
-      # compression active the true byte share is lower, which is consistent
-      # with there being little headroom left for a better algorithm.
-      #
-      # Kept because zstd is not worse than pglz and costs nothing. It is simply
-      # not a lever. The real one on this cluster was archive_timeout, below.
+      # Measured on this cluster: full-page images are 62.4% of WAL bytes, so
+      # this is the single largest lever on recorder write volume.
       #
       # zstd, not "on": the boolean spelling resolves to pglz, the original
       # 2016-era algorithm, which is both slower and weaker than the two
@@ -113,35 +95,9 @@ spec:
       # best ratio on 8 KiB page images, and the CPU cost lands on a cluster
       # that is IO-bound on QLC NVMe, not CPU-bound.
       wal_compression: "zstd"
-      # A WAL segment is a fixed 16 MiB file, and archive_timeout forces a switch
-      # on a timer -- the segment is then written and archived at its full size
-      # no matter how little real WAL it holds. CNPG defaults to 5min, i.e. up
-      # to 288 segments/day = 4.6 GB/day that is largely padding.
-      #
-      # Verified on gf-pg first (the staged rollout): 211 -> 41 MB/hour, an 81%
-      # cut, with archived segments falling from ~12/hour to ~1.5/hour in step.
-      # Two independent signals moving together is what confirms the volume was
-      # padding rather than data.
-      #
-      # The cost is RPO: up to 30min of WAL is unrecoverable if this cluster and
-      # its volume are lost outright. This is a single-instance cluster, so the
-      # archive is the only off-node copy.
-      archive_timeout: "30min"
       # Fewer checkpoints => fewer full-page writes, since a page is only
-      # fully-logged on its first modification after a checkpoint.
-      #
-      # That reasoning did not show up in WAL volume: 15min -> 30min moved the
-      # WAL rate not at all (4911/4976 -> 5002 MB/day). The likely reason is
-      # that this workload is append-mostly -- a page is dirtied while it fills
-      # and then not touched again, so its full-page image is paid once
-      # regardless of how often checkpoints run. Interval only helps pages that
-      # are re-dirtied across many cycles, which is not what a recorder does.
-      #
-      # Kept, but NOT because WAL improved. checkpoint_timeout also governs
-      # data-file writes at checkpoint, and those are unmeasured here: this
-      # volume takes ~11 GB/day against 4.9 GB/day of WAL, so most of its
-      # traffic is outside what the WAL measurement covers. Revisit with a
-      # data-file measurement before treating this value as justified.
+      # fully-logged on its first modification after a checkpoint. Doubling the
+      # interval halves how often each hot page pays that 8 KiB toll.
       #
       # Recovery cost is bounded by how much WAL a single interval produces,
       # not by the interval itself: at the measured rate 30min is well under

kubernetes/apps/home-assistant/zigbee2mqtt-config.yaml

@@ -176,22 +176,3 @@ data:
         friendly_name: Treppenhaus Haustür Schalter 1
       '0x001788010b00d011':
         friendly_name: Treppenhaus Haustür Schalter 2
-      # Ecowitt WS90 weather station. Joined after the ZHA-mirrored block above
-      # was written, hence listed apart from it.
-      #
-      # The station transmits every 8.8s, as a burst of seven per-cluster ZCL
-      # frames; Z2M publishes its full cumulative state once per frame. debounce
-      # merges a burst into one publish carrying the last value per attribute,
-      # and must stay below the transmit interval — a window that never sees
-      # silence never flushes.
-      #
-      # The firmware drops all readings to zero for a few seconds every few
-      # days. Merged, that surfaces as a single all-zero frame; unmerged, the
-      # zeros spread across the seven frames and none of them is individually
-      # distinguishable from a valid reading.
-      #
-      # Z2M reads this only at startup (requiresRestart), and this file is
-      # SEED-ONLY per the header — the running instance takes it from its PVC.
-      '0xc02cedfffe958f40':
-        friendly_name: Wetterstation
-        debounce: 2

kubernetes/apps/home-assistant/zigbee2mqtt-deployment.yaml

@@ -158,7 +158,7 @@ spec:
           # Pinned tag. No Flux image-automation marker yet (unlike mosquitto) —
           # add an infrastructure/image-automation/zigbee2mqtt.yaml policy as a
           # follow-up if desired; pinned-and-manual is fine for the initial cutover.
-          image: ghcr.io/koenkk/zigbee2mqtt:2.13.0
+          image: ghcr.io/koenkk/zigbee2mqtt:2.12.1
           imagePullPolicy: IfNotPresent
           env:
             - name: TZ

kubernetes/apps/immich/cluster.yaml

@@ -46,20 +46,6 @@ spec:
       # and slower than the lz4/zstd this build also accepts). Compresses the
       # full-page images that dominate WAL volume after each checkpoint.
       wal_compression: "zstd"
-      # A WAL segment is a fixed 16 MiB file, and archive_timeout forces a switch
-      # on a timer -- the segment is then written and archived at its full size
-      # no matter how little real WAL it holds. CNPG defaults to 5min, i.e. up
-      # to 288 segments/day = 4.6 GB/day that is largely padding.
-      #
-      # Verified on gf-pg first (the staged rollout): 211 -> 41 MB/hour, an 81%
-      # cut, with archived segments falling from ~12/hour to ~1.5/hour in step.
-      # Two independent signals moving together is what confirms the volume was
-      # padding rather than data.
-      #
-      # The cost is RPO: up to 30min of WAL is unrecoverable if this cluster and
-      # its volume are lost outright. This is a single-instance cluster, so the
-      # archive is the only off-node copy.
-      archive_timeout: "30min"
       # Write-reduction tuning. These databases are largely idle, and the
       # Postgres defaults favour throughput over storage that wears out.
       #

kubernetes/apps/immich/redis.yaml

@@ -27,7 +27,7 @@ spec:
         # Pinned to 7.4-alpine to match the LXC 225 compose exactly.
         # Any redis major-version bump is a separate migration.
         - name: redis
-          image: redis:7.4.11-alpine # {"$imagepolicy": "flux-system:redis-immich"}
+          image: redis:7.4.10-alpine # {"$imagepolicy": "flux-system:redis-immich"}
           args:
             - redis-server
             - --save

kubernetes/apps/monitoring-rules/kustomization.yaml

@@ -8,7 +8,6 @@ resources:
   - prometheusrule-cilium.yaml
   - prometheusrule-hetzner-backup.yaml
   - prometheusrule-loki.yaml
-  - prometheusrule-mariadb-backup.yaml
   - prometheusrule-netbird-availability.yaml
   - prometheusrule-netbird-backup.yaml
   - prometheusrule-netbird-ingress.yaml

kubernetes/apps/monitoring-rules/prometheusrule-ceph.yaml

@@ -12,66 +12,18 @@ spec:
     - name: ceph.rules
       rules:
         - alert: CephHealthWarn
-          # Per-check rather than ceph_health_status, so one permanently-active
-          # check cannot mask every other Ceph warning.
-          #
-          # AUTH_INSECURE_* is excluded: it cannot clear until the nodes run a
-          # kernel supporting aes256k over the CSI mount path (#527).
-          #
-          # POOL_NO_REDUNDANCY is in scope. An unreplicated pool makes
-          # `ceph osd ok-to-stop` refuse for every OSD, so it reports blocked
-          # maintenance and not just data risk — do not exclude it for a pool
-          # that is unreplicated deliberately.
-          #
-          # 6h: Ceph warns for self-clearing conditions. Only a warning that
-          # does not clear is worth paging on.
-          #
-          # BLUESTORE_SLOW_OP_ALERT breaks that premise and is still NOT
-          # excluded (#557). Ceph holds the check for
-          # bluestore_slow_ops_warn_lifetime (24h) after the LAST slow op, so
-          # one multi-second stall outlives the 6h `for` and always pages,
-          # with latency back to normal long before anyone looks. Measured:
-          # three episodes in the 30d to 2026-08-24 (Sun Jul 26, Aug 2 and
-          # Aug 23), each ran ~24-26h and cleared untouched.
-          #
-          # All began inside the weekly Velero restore-test window (Sun 08:00Z
-          # plus up to 6h, see velero/restore-test-cronjob.yaml) — a sustained
-          # restore that outruns the SLC cache on these QLC NVMe. Expected for
-          # the hardware, but not excludable: this is also the earliest signal
-          # of a genuinely failing drive, and all three are at 80-87%
-          # endurance used (see cephcluster.yaml).
-          #
-          # No metric names the stalling OSD: ceph_health_detail carries no osd
-          # label, and ceph_daemon_health_metrics{type="SLOW_OPS"} reads 0 at
-          # every scrape (a stall is shorter than the scrape interval). Only
-          # the OSD's own log has it, hence the Loki query in the description.
-          # Jul 26 and Aug 2 hit osd.0+1+2 together, which is load-driven;
-          # Aug 23 hit osd.1 alone in one burst. If osd.1 alone repeats,
-          # suspect that drive rather than the restore load.
-          expr: ceph_health_detail{name!~"AUTH_INSECURE_.+"} == 1
+          # ceph_health_status: 0 = HEALTH_OK, 1 = HEALTH_WARN, 2 = HEALTH_ERR.
+          # 6h is deliberately long. Ceph warns for self-clearing conditions —
+          # a slow BlueStore op during the Sunday restore sweep, a mon briefly
+          # below its disk threshold — and paging on those trains people to
+          # ignore the alert. What matters is a warning that does not clear.
+          expr: ceph_health_status == 1
           for: 6h
           labels:
             severity: warning
           annotations:
-            summary: "Ceph health check {{ $labels.name }} active for 6h"
-            description: "Ceph health check {{ $labels.name }} has been active for six hours. Only AUTH_INSECURE_* is excluded (kernel-blocked, see #527). BLUESTORE_SLOW_OP_ALERT is sticky for 24h after the last stall and clears itself: check whether the stall fell inside the Sunday 08:00-14:00Z Velero restore-test window (08:00 start, 6h activeDeadlineSeconds cap), which is expected on these QLC drives — one outside that window, or a repeat on the same OSD, means check that drive (#557). No metric names the OSD — get it from Loki, which also works after the check clears: `{namespace=\"rook-ceph\",pod=~\"rook-ceph-osd-.*\"} |= \"slow operation observed\"`. While still active, `kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph health detail` adds the op detail."
-
-        - alert: CephPoolLostRedundancy
-          # Names the pool, which POOL_NO_REDUNDANCY does not.
-          #
-          # There is no pool-size metric, but bytes_used/stored IS the
-          # replication factor. The >1e6 floor drops pools too small to measure
-          # meaningfully, empty ones included.
-          #
-          # No pool is exempt.
-          expr: |
-            ceph_pool_bytes_used / ceph_pool_stored < 1.5 and ceph_pool_stored > 1e6
-          for: 30m
-          labels:
-            severity: critical
-          annotations:
-            summary: "Ceph pool {{ $labels.pool_id }} is running unreplicated"
-            description: "Pool {{ $labels.pool_id }} has a replication factor below 1.5, meaning a single OSD loss destroys data. No pool is meant to be unreplicated — an unreplicated pool also blocks ALL OSD maintenance cluster-wide, since `ceph osd ok-to-stop` refuses while its PGs would go offline. Check with `kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph osd pool ls detail`."
+            summary: "Ceph has been HEALTH_WARN for 6h"
+            description: "The Ceph cluster has held HEALTH_WARN for six hours, so it is not a self-clearing blip. Get the detail with `kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph health detail`."
 
         - alert: CephHealthError
           # HEALTH_ERR means data availability or redundancy is at risk.

kubernetes/apps/monitoring-rules/prometheusrule-mariadb-backup.yaml

@@ -1,51 +0,0 @@
-apiVersion: monitoring.coreos.com/v1
-kind: PrometheusRule
-metadata:
-  name: mariadb-backup
-  namespace: monitoring
-  labels:
-    # kube-prometheus-stack's Prometheus selects on this label.
-    release: kube-prometheus-stack
-spec:
-  groups:
-    - name: mariadb-backup.rules
-      rules:
-        - alert: WordpressMariadbBackupStale
-          # The nightly 02:45 logical dump (kubernetes/apps/wordpress/mariadb.yaml)
-          # is the only transaction-consistent copy of www.renner.uno's database
-          # — Velero snapshots the PVC, which for a running DB is not a restore
-          # point you would trust.
-          #
-          # KubeJobFailed already covers a failed Job, but only while the Job
-          # object survives. On #550 it cleared when the failed Job was
-          # garbage-collected, not when a backup succeeded — so a failure that
-          # is GC'd before anyone looks leaves no signal at all.
-          # lastSuccessfulTime lives on the CronJob and outlives Job GC.
-          #
-          # 26h = one missed cycle plus 2h slack, matching NetbirdVpsBackupStale.
-          # It counts any Job owned by the CronJob, so a manual
-          # `kubectl create job --from=cronjob/...` re-run clears it too.
-          expr: |
-            time() - kube_cronjob_status_last_successful_time{namespace="wordpress", cronjob="wordpress-mariadb-backup"} > 26 * 3600
-          for: 30m
-          labels:
-            severity: warning
-          annotations:
-            summary: "WordPress MariaDB backup has not succeeded in 26h+"
-            description: "The wordpress-mariadb-backup CronJob's last successful run is over 26 hours old. Check the newest Job's pod logs in the wordpress namespace: `kubectl -n wordpress get jobs`. The 2026-08-19 failure was `The specified bucket does not exist.` against renner-uno-k8s-mariadb while the endpoint itself probed healthy, so a green HetznerBackupEndpointDown does not clear this."
-
-        - alert: WordpressMariadbBackupNeverRan
-          # The staleness expression above goes blind when the metric is
-          # absent, which is what happens once the operator recreates the
-          # CronJob. Without this guard "never backed up" is quieter than
-          # "backed up late".
-          expr: |
-            kube_cronjob_created{namespace="wordpress", cronjob="wordpress-mariadb-backup"}
-            unless
-            kube_cronjob_status_last_successful_time{namespace="wordpress", cronjob="wordpress-mariadb-backup"}
-          for: 6h
-          labels:
-            severity: warning
-          annotations:
-            summary: "WordPress MariaDB backup has no recorded successful run"
-            description: "The wordpress-mariadb-backup CronJob exists but has no lastSuccessfulTime: either it has not completed once since the Backup CR was recreated, or every run since has failed. Check `kubectl -n wordpress get jobs` and that the hetzner-s3-creds ExternalSecret is synced."

kubernetes/apps/paperless/cluster.yaml

@@ -58,18 +58,6 @@ spec:
       # and slower than the lz4/zstd this build also accepts). Compresses the
       # full-page images that dominate WAL volume after each checkpoint.
       wal_compression: "zstd"
-      # A WAL segment is a fixed 16 MiB file, and archive_timeout forces a switch
-      # on a timer -- the segment is then written and archived at its full size
-      # no matter how little real WAL it holds. CNPG defaults to 5min, i.e. up
-      # to 288 segments/day = 4.1 GB/day that is largely padding.
-      #
-      # Verified on gf-pg first (the staged rollout): 211 -> 41 MB/hour, an 81%
-      # cut, with archived segments falling from ~12/hour to ~1.5/hour in step.
-      #
-      # The cost is RPO: up to 30min of WAL is unrecoverable if both instances
-      # are lost. The documents themselves live on the media PVC, not in
-      # Postgres -- this database holds their metadata.
-      archive_timeout: "30min"
     # See ak-pg cluster.yaml for the rationale on synchronous replication.
     synchronous:
       method: any

kubernetes/apps/paperless/redis.yaml

@@ -25,7 +25,7 @@ spec:
           type: RuntimeDefault
       containers:
         - name: redis
-          image: redis:8.10.1-alpine # {"$imagepolicy": "flux-system:redis-paperless"}
+          image: redis:8.10.0-alpine # {"$imagepolicy": "flux-system:redis-paperless"}
           args:
             - redis-server
             - --save

kubernetes/apps/trmnl/cluster.yaml

@@ -36,20 +36,6 @@ spec:
       # and slower than the lz4/zstd this build also accepts). Compresses the
       # full-page images that dominate WAL volume after each checkpoint.
       wal_compression: "zstd"
-      # A WAL segment is a fixed 16 MiB file, and archive_timeout forces a switch
-      # on a timer -- the segment is then written and archived at its full size
-      # no matter how little real WAL it holds. CNPG defaults to 5min, i.e. up
-      # to 288 segments/day = 4.6 GB/day that is largely padding.
-      #
-      # Verified on gf-pg first (the staged rollout): 211 -> 41 MB/hour, an 81%
-      # cut, with archived segments falling from ~12/hour to ~1.5/hour in step.
-      # Two independent signals moving together is what confirms the volume was
-      # padding rather than data.
-      #
-      # The cost is RPO: up to 30min of WAL is unrecoverable if this cluster and
-      # its volume are lost outright. This is a single-instance cluster, so the
-      # archive is the only off-node copy.
-      archive_timeout: "30min"
       # Write-reduction tuning. These databases are largely idle, and the
       # Postgres defaults favour throughput over storage that wears out.
       #

kubernetes/apps/woodpecker/agent.yaml

@@ -34,7 +34,7 @@ spec:
           # Image automation, range 3.x (see image-automation/woodpecker.yaml).
           # MUST stay version-matched with woodpecker-server (gRPC parity) — both
           # track the same range/filter so they bump together on each release.
-          image: woodpeckerci/woodpecker-agent:v3.18.0 # {"$imagepolicy": "flux-system:woodpecker-agent"}
+          image: woodpeckerci/woodpecker-agent:v3.17.0 # {"$imagepolicy": "flux-system:woodpecker-agent"}
           env:
             - name: WOODPECKER_SERVER
               value: woodpecker.woodpecker.svc.cluster.local:9000 # in-cluster gRPC, replaces LXC :9000
@@ -50,39 +50,12 @@ spec:
             # clone + subsequent steps share the workspace PVC and the k8s backend
             # can schedule them on different nodes -> an RWO volume then fails to
             # mount on the second node. CephFS (RWX) lets the workspace follow
-            # the pipeline across nodes. Reclaim MUST be Delete: workspaces are
-            # throwaway, and a Retain class leaked one Released PV per finished
-            # pipeline (issue #262 follow-up).
-            #
-            # ceph-filesystem-ci, not ceph-filesystem-ephemeral: a dedicated
-            # CephFS whose pools are BOTH size 1 (infrastructure/
-            # rook-ceph-cluster/cephfs-ci.yaml). The shared filesystem
-            # replicates data0 2x and metadata 3x, which is the correct trade
-            # for real data and pure waste for a git clone that is deleted
-            # minutes later.
-            #
-            # Measured 2026-08-21, polling both pools every 15s (a 5-minute
-            # interval misses an entire pipeline -- PVC created, used and
-            # deleted inside ~2 minutes):
-            #   CI active  1.5min: data0 143.2 MB, metadata 17.2 MB
-            #   CI idle   16.0min: data0   0.0 MB, metadata 11.0 MB
-            # data0 write volume is 100% CI. Per pipeline this moves the drive
-            # cost from 71.6x2 + 8.2x3 = ~168 MB to ~80 MB.
-            #
-            # ceph-filesystem-ephemeral is NOT repointed, and the reason is a
-            # technical constraint rather than a safety one. Its other consumer
-            # is velero/restore-test.sh, whose probe PVCs are snapshot CLONES:
-            # `ceph fs subvolume snapshot clone` operates within one filesystem,
-            # so a snapshot taken in `cephfs` cannot be cloned into `cephfs-ci`.
-            #
-            # Those probes are just as throwaway as a CI workspace -- the
-            # authoritative copy is the backup on Hetzner, and a lost probe just
-            # means re-running the test -- so they are equally undeserving of
-            # replication. Landing them unreplicated would mean a second size-1
-            # data pool inside `cephfs`, and restore-test runs WEEKLY against
-            # CI's ~96 pipelines/day, so it is not worth the complexity.
+            # the pipeline across nodes. The -ephemeral variant (reclaim Delete,
+            # rook-ceph-cluster/storageclass.yaml) is REQUIRED here: workspaces
+            # are throwaway, and the Retain class leaked one Released PV per
+            # finished pipeline (issue #262 follow-up).
             - name: WOODPECKER_BACKEND_K8S_STORAGE_CLASS
-              value: ceph-filesystem-ci
+              value: ceph-filesystem-ephemeral
             - name: WOODPECKER_BACKEND_K8S_STORAGE_RWX
               value: "true"
             # MUST be a JSON object literal — the backend json.Unmarshal's this

kubernetes/apps/woodpecker/cluster.yaml

@@ -80,20 +80,6 @@ spec:
       # and slower than the lz4/zstd this build also accepts). Compresses the
       # full-page images that dominate WAL volume after each checkpoint.
       wal_compression: "zstd"
-      # A WAL segment is a fixed 16 MiB file, and archive_timeout forces a switch
-      # on a timer -- the segment is then written and archived at its full size
-      # no matter how little real WAL it holds. CNPG defaults to 5min, i.e. up
-      # to 288 segments/day = 4.6 GB/day that is largely padding.
-      #
-      # Verified on gf-pg first (the staged rollout): 211 -> 41 MB/hour, an 81%
-      # cut, with archived segments falling from ~12/hour to ~1.5/hour in step.
-      # Two independent signals moving together is what confirms the volume was
-      # padding rather than data.
-      #
-      # The cost is RPO: up to 30min of WAL is unrecoverable if this cluster and
-      # its volume are lost outright. This is a single-instance cluster, so the
-      # archive is the only off-node copy.
-      archive_timeout: "30min"
   resources:
     requests:
       cpu: 100m

kubernetes/apps/woodpecker/server.yaml

@@ -40,7 +40,7 @@ spec:
           # minor + patch auto-update within 3.x; only the 4.0 major is held for
           # a reviewed bump. Safe now the DB is postgres (the old sqlite-surprise
           # -bump hazard is gone). Stays in lockstep with the agent.
-          image: woodpeckerci/woodpecker-server:v3.18.0 # {"$imagepolicy": "flux-system:woodpecker-server"}
+          image: woodpeckerci/woodpecker-server:v3.17.0 # {"$imagepolicy": "flux-system:woodpecker-server"}
           env:
             - name: WOODPECKER_HOST
               value: https://ci.renner.uno

kubernetes/infrastructure/openbao/rotation/claude-oauth.yaml

@@ -51,15 +51,7 @@ spec:
   startingDeadlineSeconds: 3600
   jobTemplate:
     spec:
-      # 4 (not the sibling rotators' 1-2) because this is the only DAILY
-      # rotator — every other CronJob here is quarterly, so it takes ~90x as
-      # many runs and is correspondingly more exposed to per-run transients.
-      # backoffLimit: 1 gave two attempts ~11 s apart, and on 2026-08-19 a
-      # sub-minute resolver transient took both out (Job
-      # claude-oauth-secret-sync-29785100, BackoffLimitExceeded), costing a
-      # day's sync. 4 spreads the attempts over ~150 s (10/20/40/80 s backoff),
-      # still well inside activeDeadlineSeconds.
-      backoffLimit: 4
+      backoffLimit: 1
       activeDeadlineSeconds: 300
       ttlSecondsAfterFinished: 259200 # 3 d
       template:

kubernetes/infrastructure/rook-ceph-cluster/cephcluster.yaml

@@ -17,17 +17,6 @@ spec:
     modules:
       - name: pg_autoscaler
         enabled: true
-  # Rotates daemon keys to aes256k for CVE-2025-30156 (#527). Opt-in; disabled
-  # by default. Increment keyGeneration to rotate again.
-  #
-  # Daemon keys only — aes256k over the CSI mount path needs kernel 7.0+ and
-  # these nodes run 6.18, so CSI stays on aes and the client-key checks stay
-  # raised. keyType is unset so Rook picks it.
-  security:
-    cephx:
-      daemon:
-        keyRotationPolicy: KeyGeneration
-        keyGeneration: 2
   # Bump CephFS subvolume cloner pool from 4 → 16. Velero CSI Snapshot
   # Data Movement provisions a backupPVC per source PVC by cloning the
   # VolumeSnapshot, and a 4-thread default stalls migrate-immich's

kubernetes/infrastructure/rook-ceph-cluster/cephfs-ci.yaml

@@ -1,64 +0,0 @@
----
-# A SEPARATE CephFS whose only purpose is Woodpecker CI workspaces. Each
-# pipeline gets a PVC that is created, filled and deleted within ~2 minutes;
-# keeping that churn off `cephfs` spares its size-3 metadataPool.
-#
-# size 2, not 1: an unreplicated pool makes `ceph osd ok-to-stop` refuse for
-# every OSD, blocking all OSD maintenance cluster-wide. size 1 is viable only
-# once these pools have OSDs of their own.
-apiVersion: ceph.rook.io/v1
-kind: CephFilesystem
-metadata:
-  name: cephfs-ci
-  namespace: rook-ceph
-spec:
-  metadataPool:
-    replicated:
-      size: 2
-  dataPools:
-    - name: data0
-      replicated:
-        size: 2
-  metadataServer:
-    activeCount: 1
-    # No standby-replay, unlike `cephfs`. A standby exists there so a failed
-    # MDS does not hang every CephFS mount cluster-wide; here the only casualty
-    # is a running pipeline, and a second daemon to protect throwaway work is
-    # not worth its memory.
-    activeStandby: false
-    resources:
-      # Deliberately NOT the 4Gi that `cephfs` needs. That figure is driven by
-      # immich's millions of cached inodes; a CI workspace is a few thousand
-      # short-lived files that vanish with the pipeline.
-      requests:
-        cpu: 100m
-        memory: 512Mi
-      limits:
-        memory: 1Gi
----
-# CI-only class. `ceph-filesystem-ephemeral` is deliberately left pointing at
-# the main filesystem: velero/restore-test.sh uses it to restore REAL data for
-# verification, which must not land on unreplicated pools.
-#
-# A new class rather than repointing the old one — StorageClass.parameters are
-# immutable, so `fsName` cannot be edited in place.
-apiVersion: storage.k8s.io/v1
-kind: StorageClass
-metadata:
-  name: ceph-filesystem-ci
-provisioner: rook-ceph.cephfs.csi.ceph.com
-parameters:
-  clusterID: rook-ceph
-  fsName: cephfs-ci
-  pool: cephfs-ci-data0
-  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
-  csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
-  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner
-  csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph
-  csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
-  csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
-# Delete, for the same reason ceph-filesystem-ephemeral uses it: with Retain,
-# every finished pipeline leaks a Released PV pinning a subvolume (191 of them
-# by 2026-07-16, issue #262 follow-up).
-reclaimPolicy: Delete
-allowVolumeExpansion: true

kubernetes/infrastructure/rook-ceph-cluster/kustomization.yaml

@@ -4,6 +4,5 @@ resources:
   - cephcluster.yaml
   - toolbox.yaml
   - storageclass.yaml
-  - cephfs-ci.yaml
   - volumesnapshotclass.yaml
   - objectstore.yaml