Derived from the copies below, never declared. Writable and auto failover need nobody; reads only means a copy here keeps serving while writes wait for a promotion; restore required means the only thing reachable is a backup.

Whether a path depends on the home uplink is walked through the inventory, not declared: the mesh tunnel does not mention the ISP uplink, it depends on it.

Each store this estate cannot afford to lose, with both of its recovery points, every copy and what it takes to get it back.

Task state, the scheduler's leader lease, node identities and every record of what JarvisOS has done. Losing it does not degrade the estate, it forgets it.

Written by

single writer — one primary, promotion is a separate act, primary on home1

Recovery point — anywhere

30s today · promised 15m

Recovery point — losing the site

30s today · promised 1h

Copies

5 today, 6 by design, across fd-vps, fd-home-rack, fd-offsite

Last restore drill

2026-07-12 · pass in 22m

Home uplink

writes do not cross it; every off-site copy crosses it

• The scheduler's leader lease lives in this store on purpose: whoever can write the lease row is by definition the side that can write the data. See docs/CONTROL-PLANE-HA.md.
• The 2026-07-12 drill restored from the NAS, which is in the same room as the primary. The restore that matters — from gwscli-s3-offsite, onto VIN, with nothing at home reachable — has never been run. That is the quarterly drill this register exists to schedule.

• ◑ Home1 is gone: pg-replica-vin keeps serving reads here; writes resume once a human promotes it.
• ● VIN (the VPS) is gone: The primary is on this side. Reads and writes continue.
• ● Home internet is down: The primary is on this side. Reads and writes continue.
• ● The mesh is partitioned: The primary is on this side. Reads and writes continue.
• ● The NAS is gone: The primary is on this side. Reads and writes continue.

Lets VIN keep working when the home uplink does not. Task results, telemetry and evidence are written here first and drained into Postgres when the mesh returns, so a home internet outage costs latency rather than work.

Not watched: Planned. Nothing runs on VIN to declare yet, so the inventory has no entity for it and the health engine cannot see it.

Written by

local-first — writes land locally and drain later, primary on vin

Recovery point — anywhere

none today (15m by design) · promised 15m

Recovery point — losing the site

none today (15m by design) · promised 15m

Copies

1 today, 2 by design, across fd-offsite, fd-vps

Last restore drill

never

Home uplink

writes do not cross it; no off-site copy crosses it

• The reason this store exists is a finding on jarvisos-postgres: without it, VIN writes across the home uplink and stops when the house does.

• ● Home1 is gone: The primary is on this side. Reads and writes continue.
• ✕ VIN (the VPS) is gone: No copy of this data is reachable from this side of the break.
• ✕ Home internet is down: No copy of this data is reachable from this side of the break.
• ✕ The mesh is partitioned: No copy of this data is reachable from this side of the break.
• ● The NAS is gone: The primary is on this side. Reads and writes continue.

Session state for the SSO chokepoint and the short-lived job queue. Losing it logs everyone out and drops in-flight jobs; it does not lose anything that was ever committed.

Written by

single writer — one primary, promotion is a separate act, primary on home1

Recovery point — anywhere

none today

Recovery point — losing the site

none today

Copies

1 today, 1 by design, across fd-home-rack

Last restore drill

never

Home uplink

writes cross it; no off-site copy crosses it

• The fix for the uplink dependency is not to replicate this store — it is rebuildable, so replicating it buys little. It is to move it: a Redis on VIN, with home1 pointing at it, puts the session store on the same node as the auth service that needs it and leaves nothing crossing the uplink on the login path. That is a placement change, tracked as its own task rather than smuggled in here.

• ⛁ Home1 is gone: Start an empty Redis. Every user re-authenticates against Google on their next request; the job queue refills from the tasks table in jarvisos-postgres, which is authoritative for anything that had actually been accepted.
• ● VIN (the VPS) is gone: The primary is on this side. Reads and writes continue.
• ● Home internet is down: The primary is on this side. Reads and writes continue.
• ● The mesh is partitioned: The primary is on this side. Reads and writes continue.
• ● The NAS is gone: The primary is on this side. Reads and writes continue.

Every application, server, destination, environment variable and deployment history Coolify holds. Losing it does not stop what is already running — it stops anything from being deployed, redeployed, restarted or rolled back, including the deploy that would replace whatever just failed.

Not watched: It runs inside Coolify's compose stack on home1 and is not declared in the inventory, so nothing here probes it. Coolify is the only thing that knows whether it is healthy.

Written by

single writer — one primary, promotion is a separate act, primary on home1

Recovery point — anywhere

1d today · promised 1d

Recovery point — losing the site

none today (1d by design) · promised 1d

Copies

2 today, 4 by design, across fd-home-rack, fd-offsite

Last restore drill

never

Home uplink

writes do not cross it; no off-site copy crosses it

• This is the store the estate-disposition register calls its single lifecycle point: while home1 is down, nothing in the estate can be deployed. See docs/ESTATE-DISPOSITION.md.
• The version pinning in the restore steps is not pedantry. Coolify migrates its own schema on boot, so a dump taken before an upgrade cannot be restored into the version that follows it.

• ✕ Home1 is gone: No copy of this data is reachable from this side of the break.
• ● VIN (the VPS) is gone: The primary is on this side. Reads and writes continue.
• ● Home internet is down: The primary is on this side. Reads and writes continue.
• ● The mesh is partitioned: The primary is on this side. Reads and writes continue.
• ● The NAS is gone: The primary is on this side. Reads and writes continue.

The user-facing edge database: auth, row-level security and the tables the public apps read through PostgREST. It is where a browser writes; JarvisOS Postgres is where the estate's own record lives.

Not watched: Vendor-held. There is no host of ours to probe and no entity to declare; what we can see is what the API answers.

Written by

vendor-managed — the provider decides, and does not say how, held by Supabase (eu-central-1)

Recovery point — anywhere

1d today · promised 1d

Recovery point — losing the site

1d today · promised 1d

Copies

2 today, 3 by design, across fd-home-rack, fd-offsite, vendor-supabase

Last restore drill

never

Home uplink

writes do not cross it; every off-site copy crosses it

• Supabase stays where user-facing auth and realtime live, because replacing GoTrue is a project rather than a migration. What changes here is that the estate stops relying on the vendor being the only place the data exists: a nightly logical dump is pulled to the NAS and pushed off-site, under our own encryption, so an account or billing problem is an inconvenience rather than a data loss.
• Nothing in this register holds a Supabase credential. The dump job reads its connection string from /etc/jarvisos/config.env, which is not in this repository.

• ● Home1 is gone: The primary is on this side. Reads and writes continue.
• ● VIN (the VPS) is gone: The primary is on this side. Reads and writes continue.
• ⛁ Home internet is down: Only supabase-dump-nas is reachable; recovery here means restoring it.
• ● The mesh is partitioned: The primary is on this side. Reads and writes continue.
• ● The NAS is gone: The primary is on this side. Reads and writes continue.

A migration is a write to every copy. Expand-contract survives a replica applying the old shape and a rollback that lands on the previous release; anything else has to say what it can be undone from and what that costs.

1. Expand: ADD COLUMN owner text NULL. Nothing reads it yet, and a nullable column is invisible to the running release.
2. Backfill in batches of 1000 with a sleep between, so replication lag stays under the 30s the recovery point assumes.
3. Deploy the release that writes and reads the column.
4. Contract, one release later: SET NOT NULL once the backfill is proven complete.

Verified by: SELECT count(*) FROM tasks WHERE owner IS NULL returns zero before the contract step, and the previous release still boots against the expanded schema.

The shape of every migration to this store: each step is safe on its own, the old release keeps running against the new schema, and no step needs the replica to have caught up.

1. Confirm the newest pg-base-nas snapshot is under 6h old and that pg-wal-nas is current.
2. Drain jarvisos-vin-journal to zero and hold the worker. A queue can be holding rows written by a release that predates this change, and they still have to land.
3. RENAME the table to heartbeats_legacy_20260901 and leave it for one full retention period.
4. DROP it only after that period, and only if nothing has asked for it.

Verified by: No error in the control-plane log referencing the table for a full retention period after the rename.

The rename-then-drop is what makes an irreversible change reversible for a retention period. The restore path exists for the case where someone skips the wait.

1. Expand: ADD COLUMN node_seq integer NULL and a unique index on (node_id, node_seq) WHERE node_seq IS NOT NULL.
2. New writes carry the sequence; queued rows written by the previous release do not, and drain unchanged.
3. Contract only once the queue has drained to zero at least once under the new release.

Verified by: A disconnect-and-drain with rows written by both releases in the queue, ending at zero depth with no duplicate rows in Postgres.

A local-first store makes the expand-contract rule non-negotiable: at any moment the queue may hold rows written by a release that is no longer installed, and they still have to drain.

• § Accepted risk: Fewer independent copies than policy requires. jarvisos-vin-journal
  JarvisOS VIN journal exists in 1 place(s) today; policy wants 3. Planned: journal-offsite-s3.
  Accepted by homelab-operator, review 2027-02-01: This is a bounded queue, not a system of record. Anything in it is either drained into Postgres within minutes — where the three-copy rule does apply — or it is still in flight. A third copy of a queue protects nothing that Postgres is not already protecting, and it would cost a second place for unfinished work to leak from.

• i Note: A store has no inventory entity, so nothing here can tell whether it is up. jarvisos-vin-journal
  JarvisOS VIN journal has no inventory entity, so nothing here can tell whether it is up: Planned. Nothing runs on VIN to declare yet, so the inventory has no entity for it and the health engine cannot see it.
• i Note: The design meets its objectives only because of copies that are not running yet. jarvisos-vin-journal
  JarvisOS VIN journal reaches 15m / site 15m only once journal-offsite-s3 is running. Today it is none / site none.
• i Note: A store has no inventory entity, so nothing here can tell whether it is up. coolify-state
  Coolify's own Postgres has no inventory entity, so nothing here can tell whether it is up: It runs inside Coolify's compose stack on home1 and is not declared in the inventory, so nothing here probes it. Coolify is the only thing that knows whether it is healthy.
• i Note: The design meets its objectives only because of copies that are not running yet. coolify-state
  Coolify's own Postgres reaches 1d / site 1d only once coolify-dump-nas, coolify-dump-offsite are running. Today it is 1d / site none.
• i Note: A store has no inventory entity, so nothing here can tell whether it is up. supabase-edge
  Supabase (edge database) has no inventory entity, so nothing here can tell whether it is up: Vendor-held. There is no host of ours to probe and no entity to declare; what we can see is what the API answers.
• i Note: The design meets its objectives only because of copies that are not running yet. supabase-edge
  Supabase (edge database) reaches 1d / site 1d only once supabase-dump-offsite is running. Today it is 1d / site 1d.

• Two recovery points are derived for every durable store, not one. The first is the best copy anywhere: it survives a dead disk in home1. The second is the best copy outside the primary's failure domain: it is the only one that survives the room. A WAL archive on the NAS is excellent at the first and worth nothing for the second.
• Off-site protection must not share one uplink. If every copy that leaves the estate is pushed over the home internet connection, then a home internet outage stops all off-site protection advancing while the primary keeps accepting writes — and nothing looks broken until the site is gone. The fix is a second off-site path that starts somewhere else, which is why the VPS pushes its own copy.
• This estate has two compute domains. A majority needs three, so nothing here promotes itself: every promotion is a human act with a fencing step, and automatic promotion of durable state is a finding rather than a feature.
• A restore nobody has run is a hypothesis. Drill evidence carries a date, an outcome and a measured duration, and it is the measurement that is checked against the RTO.
• Findings describe the estate as it runs. Where the design closes one, that appears as a note rather than as a clean bill of health.

Source: config/datastores.json · machine-readable at /api/v1/data · narrative in docs/DATA-RESILIENCE.md.