Questo articolo nasce da un problema molto concreto: sapere davvero se i backup funzionano, senza dover controllare manualmente log sparsi, script cron opachi e notifiche poco affidabili.

Nel mio homelab (che resta pur sempre una casa, non un data center enterprise) ho deciso di applicare principi da Business Continuity e Disaster Recovery tipici di ambienti professionali:

• logging deterministico e verificabile
• separazione netta tra esecuzione e controllo
• principio di fail‑closed (meglio un alert in più che un backup perso)
• audit trail esterno e immutabile

Il risultato è un’architettura che ruota attorno a Ubuntu Server, backup ridondati (Oracle Cloud + Hetzner), Google Cloud per il logging e un workflow n8n che valida ogni giorno che tutto sia andato a buon fine.

Questo articolo spiega l’architettura, le scelte tecniche e il perché. Il workflow n8n è un prodotto a pagamento: lo descrivo in modo trasparente, ma senza rilasciare informazioni sensibili o replicabili uno‑a‑uno.

---

Il problema reale (prima)

Prima di questa architettura, il flusso era il classico:

• cron job → rsync / rclone
• log locali
• controllo manuale “quando capita”
• alert solo in caso di errori evidenti

Questo approccio ha tre difetti strutturali:

1. Silenzio ≠ successo
   Se un job non parte o muore a metà, spesso non lo scopri subito.
2. Log locali = single point of failure
   Se perdi la VM, perdi anche la prova che il backup era partito.
3. Tempo umano sprecato
   Leggere log grezzi è costoso e soggetto a errori.

Da qui la decisione di over‑ingegnerizzare consapevolmente.

---

Obiettivi di progetto

Gli obiettivi non erano “fare cose fighe”, ma essere operativamente sereni:

• sapere ogni giorno se tutti i job hanno girato
• sapere quale job ha fallito e perché
• avere log immutabili fuori dal server
• poter dimostrare a posteriori cosa è successo (audit)
• zero dipendenze inverse: il controllo non deve mai toccare il server

---

Architettura ad alto livello

Ubuntu Server (on‑prem / Proxmox)
 ├─ cron
 ├─ rsync / rclone
 ├─ log strutturati
 │
 ├─ Google Cloud Logging (streaming)
 └─ Google Cloud Storage (snapshot log)
          │
          ▼
        n8n (monitoring & validation)
          │
          ├─ check presenza log
          ├─ parsing deterministico
          ├─ analisi contenuto
          └─ alert / ticket

Separazione chiave:

• Ubuntu Server esegue
• n8n osserva

Nessun SSH, nessuna API verso il server. Zero trust sul produttore del dato.

---

Ubuntu Server come fondazione

Ubuntu Server è il punto di partenza:

• VM su Proxmox
• storage locale + dischi dedicati
• script versionati (Git)
• cron semplice, ma osservabile

Log strutturati, non “testo a caso”

Ogni job di backup produce log con:

• marker di START, RSYNC_END, SUMMARY, END
• run_id univoco
• rc, durata, warning, errori

Questo permette:

• parsing deterministico
• rilevare run incompleti
• distinguere warning da failure

Non è logging “per l’uomo”, è logging per le macchine.

---

Backup ridondati ≠ Business Continuity

Fare più copie non basta.

La Business Continuity richiede:

• sapere che tutte le copie sono state aggiornate
• sapere quando una copia non lo è
• reagire in modo proporzionato

Per questo:

• Oracle Cloud e Hetzner sono solo target
• la verità è nei log
• la continuità è nella verifica automatica

---

Logging esterno: Google Cloud

Il logging è diviso in due canali complementari.

1. Google Cloud Logging (streaming)

• ingestione near‑real‑time dei log rsync
• query veloci
• troubleshooting immediato
• costi bassissimi (spesso zero)

Serve per:

• analisi
• debug
• visibilità operativa

2. Google Cloud Storage (snapshot immutabili)

• upload giornaliero dei log
• path deterministico YYYY/MM/DD
• versioning e retention
• service account con permessi minimi

Serve per:

• audit
• verifica indipendente
• input del workflow n8n

Questo bucket è la fonte di verità per il monitoring.

---

Il ruolo di n8n (monitoring, non backup)

Il workflow n8n non esegue backup.

Fa solo tre cose, in ordine:

1. Verifica presenza
   Tutti i log attesi per oggi esistono?
2. Verifica integrità
   Ogni log ha START/END/SUMMARY coerenti?
3. Verifica semantica
   Errori? Warning? Pattern anomali?

Se qualcosa manca o non torna → alert.

Perché n8n?

• workflow leggibili
• versionabili
• estendibili
• disaccoppiati dal server

Il valore non è “l’automazione”, ma la validazione.

---

Dove acquistarlo

• Shop ufficiale: https://shop.paoloronco.it
• Gumroad: https://paoloronco.gumroad.com
• n8n Creators Hub / Templates: in arrivo

Perché è un workflow a pagamento

Questo workflow:

• incapsula mesi di debug reale
• gestisce edge case (log incompleti, duplicati, run parziali)
• è pensato per essere esteso, non solo usato

Non vende magia.
Vende tempo risparmiato e errori evitati.

Dove acquistarlo

• shop.paoloronco.it
• Gumroad
• n8n Creators Hub (template)

Il codice sensibile resta mio.
L’architettura e i principi sono condivisi.

---

Sicurezza e principi chiave

• Service Account a scopo singolo
• permessi minimi
• niente credenziali nel workflow
• niente accesso diretto al server

Se n8n venisse compromesso:

• può solo leggere log pubblici per lui
• non può toccare backup o server

Questo è zero trust applicato a un homelab.

---

Cosa mi ha tolto di dosso questa architettura

• controllo manuale quotidiano
• ansia da “sarà partito?”
• debug notturni
• log inutili

In cambio ho ottenuto:

• fiducia misurabile
• alert significativi
• audit trail
• serenità operativa

---

Conclusione

Questo progetto non è nato per dimostrare che si può fare.

È nato perché non volevo più perdere tempo a dubitare dei backup.

Anche in un homelab, i dati contano.
E quando i dati contano, il logging è parte del backup, non un dettaglio.

Over‑engineering? Forse.
Ma è un over‑engineering che dorme tranquillo.