---
id: RISK-F-0006
type: finding
title: "apps-pg has no backup configured at all: R0 means no recovery"
status: open
reported_by: railiance-platform
reported_via: flex-auth
routed_by: risk-nexus
date_reported: "2026-08-17"
date_filed: "2026-08-19"
system: railiance-platform
environment: production
fix_owner: railiance-platform
fix_tracking: unset
related: [RISK-F-0001]
# Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-second-grading.md
severity: high
severity_at_production: critical
impact: I4
likelihood: L2
fidelity_modifier: false
production_rescore: true
disclosure: embargoed
embargo_condition: "a backup exists and a restore has been demonstrated once"
embargo_since: "2026-08-19"
embargo_review: "2026-09-18"
escalation: required
escalation_trigger: 3
escalation_status: pending-operator
last_reviewed: "2026-08-19"
review_by: "2026-09-18"
graded_by: risk-nexus
ruling: RISK-RULING-2026-08-19-B
---

# RISK-F-0006 — the platform database cannot be recovered

## What is true, as reported

`apps-pg` (`railiance-platform`) has no backup configured at all: no
`barmanObjectStore`, no retention policy, and `BestEffort` QoS on the pod.
Reported in the same round as `RISK-F-0001`, whose author noted that `R0` here
means **no recovery**, not merely no erasure policy.

Not verified by this repo. `railiance-platform` owns it.

## Why it is graded highest of the round despite being the least exciting

The other findings in this round are about someone reaching something. This one
is about nothing coming back. There is no attacker in it and no clever step —
an ordinary node failure, a lost volume, a mistaken `DROP`, and the data that
was in `apps-pg` is gone.

`BestEffort` QoS makes the pod the first candidate for eviction under memory
pressure. Eviction alone is an availability event and recoverable. What is not
recoverable is anything that damages the volume, and that is the case with no
answer today.

## Register ruling — 2026-08-19

`high` today (`I4` × `L2`, non-adversarial reading), `critical` at production,
embargoed, and **escalated on trigger 3 (spend)**.

`I4`: `apps-pg` is shared platform infrastructure, so the loss is not confined
to one system, and it is unrecoverable rather than degraded. `L2` on the
non-adversarial reading the scale gained for this finding: irrecoverable loss
needs a volume or corruption event, which is an ordinary failure the estate
has seen the shape of but not an expected weekly occurrence.

`production_rescore: true`: at production this is `L3`, because the surface
area of ordinary operational events grows with real traffic and real operators.

**Escalation, trigger 3.** Object storage for backups is recurring spend that
is not currently committed, and no repo can authorise it for itself. The ask
is narrow: approve a backup target and its cost, or state that the estate
accepts running `apps-pg` with no recovery and for how long. The second is a
legitimate answer in build mode and needs saying out loud rather than
happening by default.

The disclosure condition deliberately includes a demonstrated restore. A
backup nobody has restored from is a claim, not a control — the same class of
error as the gate in `RISK-F-0002`.

## Reviews

- **2026-08-19** — filed and graded from `RISK-F-0001`'s unfiled list.
  Open at review: has the spend been ruled on; is a backup configured; has a
  restore been demonstrated; does `railiance-platform` track it anywhere.