---
name: project-fragilita-nave
description: "RISOLTO 29/07/2026 — rischio SPOF della Nave documentato e accettato (RECOVERY.md/servizi.md riscritti, verificati contro stato reale). Storico della decisione."
metadata: 
  node_type: memory
  type: project
  originSessionId: c35b3ade-b2cb-4b16-9684-fcd6d0b1386d
---

La Nave è un single point of failure crescente. Con l'aggiunta di vault_guardian, elon_checklist, maintenance_check, cockpit webapp, inbox-watch e form-watch, un guasto hardware o OS sul MiniPC N150 porta giù tutto il sistema Adrian+Elon+vault.

**Why:** L'architettura è cresciuta organicamente senza un piano di resilienza esplicito. Mauro ha sollevato la questione il 2026-07-09 come nota da tenere a mente.

**How to apply:** Prima di aggiungere ulteriore complessità alla Nave, segnalare a Mauro che il tema resilienza è ancora aperto. Quando si discute di nuovi servizi critici, proporre come parte del design dove andrebbero replicati o quali dati sopravvivono a un crash.

**Aree di rischio:**
- vault.db: dati curati da Elon — se il disco si rompe senza backup recente, si perde il grafo
- Chrome profilo elon/agent: se corrotto, richiede re-autenticazione manuale
- Servizi systemd: ripartono al boot, ma il boot stesso dipende dall'hardware
- Crontab: locale alla macchina, non replicato

**Backup esistente:** restic giornaliero (03:00) + pCloud (01:15) — copertura parziale, ma non zero.

**Da fare (quando Mauro decide di affrontarlo):**
- Valutare se vault.db va replicato in real-time su VPS Avamposto
- Documentare procedura di disaster recovery (quanto tempo per ripristinare su nuovo hardware)
- Valutare se cockpit webapp può stare sul VPS come fallback

---

**AGGIORNAMENTO 29/07/2026 — sia questo file che la doc di recovery sono superati, da rifare insieme.**

Questo documento cita servizi ormai rimossi (cockpit webapp, vault_guardian, elon_checklist, inbox-watch, form-watch — tutti dismessi il 15/07/2026) e "vault.db" come dato critico, quando l'architettura AgentBricks (vedi [[project_alleggerimento_elon]]) sta dismettendo gradualmente proprio vault.db/Elon a favore dell'archivio file-based.

Il "da fare" sopra ("documentare procedura di disaster recovery") **esiste già** — `archivio/_secrets/RECOVERY.md` — ma è a sua volta superato: path pre-migrazione (`/mnt/ssd/adrian/` invece di `/mnt/ssd/data/Dropbox/adrian/`), cita Supabase (smantellato) e Albert (morto dal 29/03), crontab non corrispondente a quello reale. Stessa cosa per `archivio/_secrets/servizi.md` (datato 04/03/2026).

**Aggiornamento 29/07/2026**: tutti e quattro i file (`config.md`, `credentials.md`, `servizi.md`, `RECOVERY.md`) spostati in [[_i_secrets|_secrets]], cartella `vault/` eliminata — decisione di Mauro: dato che tutto è comunque dentro Dropbox, il rischio vero era la disciplina di non specchiarli mai verso l'esterno, non la posizione fisica; una cartella ben marcata dentro l'archivio protegge meglio di una cartella separata facile da dimenticare.

**COMPLETATO 29/07/2026**: `RECOVERY.md` (v2.0) e `servizi.md` riscritti da zero, verificati contro lo stato reale (`docker ps`, `systemctl`, `ufw status`, crontab) invece di ricopiati dalla versione stantia. Scope di `RECOVERY.md` ristretto deliberatamente — non più "tutto Adrian+Elon+vault", solo hardware/Docker/rete, perché `archivio/` è già replicato via Dropbox+git indipendentemente da un piano di recovery dedicato (il bisogno che l'aveva reso "tutto il sistema" era vault.db, in dismissione).

**RISOLTO 29/07/2026**: le due regole firewall orfane erano entrambe relitti di servizi morti — `8710/tcp` Jarvis Gateway (dismesso 04/03/2026), `8766/tcp` identificata via `git log -S"8766"` come il vecchio cockpit webapp (dismesso 15/07/2026, nessun codice attivo la referenzia). Confermato via `ss -tlnp` che nulla ascoltava su nessuna delle due porte. Rimosse entrambe da ufw su approvazione di Mauro.

Thread chiuso.