OPS-WSF-001 — Protect workspace metadata capacity and recovery
| Field | Value |
|---|---|
| Status | Open; source-verified |
| Severity | Critical recovery boundary |
| Components | sparqd/platform-stacks, KubeBlocks PostgreSQL, sparqd/workspace-file-management-backend |
| Associated issues | Not opened |
Concrete observed case
The deployment creates one PostgreSQL replica with a fixed 20 GiB volume,
disables the exporter, and sets cluster termination policy to Delete. This
database is the only catalog for public IDs, hierarchy, object keys, ACLs,
trash, and history. No workspace-file-specific backup/PITR policy, capacity
alert, high-availability objective, or restore exercise appears in the reviewed
KCL.
Expected condition
Metadata has measured growth, storage and availability alerts, a reviewed backup/PITR policy, protected deletion semantics, and a regularly tested restore that reconciles with object storage.
Why it matters
Object bytes alone cannot reconstruct names, paths, sharing, or current-version selection reliably. Database loss or disk exhaustion can make every Workspace file unavailable even when the bucket remains intact.
Existing controls and workarounds
KubeBlocks manages the database pod and persistent volume, and the bucket is configured to survive platform deletion. Whether cluster-wide backup tooling covers this database with a usable application-consistent restore has not been demonstrated.
Alternatives considered
- Recommended: KubeBlocks-supported backup/PITR, deletion protection, exporter metrics, capacity alerts, and a metadata/object reconciliation restore drill.
- Rely on cluster-volume backup only — acceptable only after a proven application-consistent restore and stated recovery objectives.
- Reconstruct metadata from object keys — rejected because keys are opaque and do not contain hierarchy or ACL truth.
Component involvement
- Platform stacks configures database durability, monitoring, backups, and deletion protection.
- KubeBlocks executes backup, failover, volume growth, and restore.
- The backend supplies consistency checks and a post-restore reconciler.
Reproduction and verification
In a disposable workspace, record file and ACL state, take a supported backup, mutate metadata and objects, restore to a point in time, and reconcile. Measure RPO, RTO, missing metadata, missing objects, and orphan objects.
Resolution conditions
Close when capacity thresholds and recovery objectives are approved and a repeatable restore exercise meets them without unauthorized access or silent file loss.
Validation and blockers
Topology and KCL settings are source-confirmed. Backup coverage, provider snapshots, recovery objectives, and a restore result are not recorded.