va-backup is the collection's insurance policy. It reads two live databases — Neon PostgreSQL and MongoDB — dumps both read-only, compresses them with zstd, hashes each with SHA-256, uploads to Cloudflare R2, verifies the upload, then writes a manifest back to GitHub. Nothing here writes to production. That single rule shapes every other decision in the machine: the primary database is chosen by a config flag, not a connection string guess, and consistency is checked before a single byte is dumped.

The engine is split by responsibility, not by feature. An external scheduler — cron-job.org — POSTs a trigger and leaves; the API only enqueues, never dumps; a separate worker process claims jobs with an atomic lock, holds a 30-second heartbeat, and executes the pipeline. A duplicate trigger with the same idempotency key returns 200 instead of enqueuing a second copy, and a worker that dies mid-job leaves a stale heartbeat that the next worker requeues. The API can live on Vercel with a 60-second budget; the worker cannot, so it runs on a container. The split is the design.

Before the backup, a consistency gate decides whether the backup is worth taking: PostgreSQL schema and index compared structurally against an expected-state snapshot, Mongo index inspected, both reduced to hashes, drift reported as PASS, WARNING, or FAIL. Only PASS and WARNING proceed — a FAIL stops the pipeline rather than preserving a broken picture. Restore is the same instinct reversed: it refuses to touch production by default, targets staging, then re-verifies schema hash, index hash, table counts, collection counts, and sample records before anyone calls the recovery finished. Every provider has a local filesystem mode, so the whole vault runs on a laptop with no credentials at all.