---
tipo: cantiere
id: resilienza-la-nave
aliases: ["Resilienza la Nave", "Single point of failure"]
nome: Resilienza la Nave
fase: chiuso
output: rischio indisponibilità accettato consapevolmente da Mauro; UPS scartato (01/07); nessun residuo
fonte: [sessione 30/06 — innesco: MCP irraggiungibile a metà sessione]
aggiornato: 2026-06-30
---
**Esito (30/06).** Rischio indisponibilità **accettato da Mauro**, non risolto tecnicamente. Dopo un blackout la Nave NON si riaccende da sola (BIOS su "stay off"): resta giù finché Mauro non preme il tasto. Mauro: "va bene così". Decisione informata, suo diritto. Unico scenario scoperto: blackout *mentre Mauro è via per giorni* → secondo cervello giù fino al rientro — giudicato fastidio tollerabile. Questo chiude anche la Pista B verso "tollerabile". Resta aperto solo l'UPS (rischio diverso: integrità disco, non disponibilità).

---

**Innesco (30/06).** A metà sessione l'MCP del vault è diventato irraggiungibile (ogni chiamata in errore, anche le letture). Tornato su da solo dopo qualche minuto. L'episodio ha messo a fuoco il rischio strutturale, non il singhiozzo: **tutto il secondo cervello vive su un solo nodo fisico in casa di Mauro** ([[la Nave]]). Single point of failure.

## I due rischi, distinti
- **Perdita dei dati** → **coperta.** Backup **Restic→HDD + pCloud dell'intero SSD** (non vault-aware: il vault è incluso *incidentalmente* perché sta sul disco — ma per la perdita i byte sono byte, copertura reale e off-machine). Più `_archivio/raw/` (verbatim Supabase) e Supabase congelato come fonte ri-derivabile. Solidi. *(Caveat noto: il backup salva anche lo stato sporco → protegge dalla perdita, non dall'integrità del grafo.)*
- **Indisponibilità** → **accettata (30/06).** Se la Nave è giù, Elon torna un LLM senza memoria finché non rientra. Mauro accetta il rischio: i blackout li becca quasi sempre a casa, e l'unico caso scoperto (via per giorni) è tollerabile. Backup ≠ disponibilità, ma la disponibilità non è un requisito per Mauro.

## Pista A — riavvio non presidiato
1. **Auto-start dei servizi al boot → ✓ CONFERMATO (30/06).** Riacceso il PC, i servizi (MCP) e il job di backup si rialzano da soli, nessun passaggio manuale dopo il boot. *(NB: non esistono cron di manutenzione da rialzare — l'unica automazione è il backup; vedi KERNEL §8.)*
2. **BIOS "restore on AC power" → CHIUSO per accettazione (30/06).** Confermato: la Nave NON si riaccende da sola dopo blackout. Mauro NON cambia l'impostazione — accetta il power-on manuale. Non è un fix, è un rischio accettato.
3. **UPS piccolo → SCARTATO (01/07).** Mauro: "non ci interessa". Proteggeva l'integrità del filesystem a mancanza corrente, ma è un rischio giudicato non prioritario. Chiuso, non riproporre.

## Pista B — indisponibilità prolungata → RISOLTA verso "tollerabile" (30/06)
La domanda era: quanto pesa restare senza secondo cervello per ~una settimana? Risposta implicita di Mauro accettando il power-on manuale: **poco, fastidio tollerabile.** La Nave-in-casa va bene, nessuno spostamento su nodo always-on esterno. Chiusa.

## Guardrail (Elon, mentore) — confermato valido
Non sovra-correggere su un evento singolo. Mauro ha tenuto la rotta: nessuna fuga al cloud per un singhiozzo. L'episodio è servito da test di resilienza non pianificato (kaizen: il guasto piccolo che rivela il punto debole prima di quello grosso), e l'esito è una scelta consapevole, non una reazione.

## Prossimo passo
Solo l'UPS, se/quando Mauro decide. Per il resto il cantiere è di fatto chiuso.