> Backup e disaster recovery per sistemi automatizzati con AI:
la parte che nessuno progetta

Chi costruisce sistemi automatizzati con AI tende a concentrarsi sul "che cosa" e il "come funziona": integrare un LLM, orchestrare agenti, connettere bot a database, mandare in produzione. Il disaster recovery arriva dopo, spesso quando il sistema ha già avuto un incidente.

Il problema è che una pipeline AI ha vulnerabilità diverse rispetto a un'app tradizionale. Non è solo una questione di database replicato e backup incrementali.

# Che cosa rischia una pipeline AI

Un sistema automatizzato con AI contiene più layer di dati e logica rispetto a un'applicazione classica:

• Stato delle conversazioni: chat con LLM, memoria contestuale, storico degli agenti. Se lo perdi, ogni utente riparte da zero.
• Modelli fine-tuned o RAG indexati: embedding, vector database, file di configurazione dei prompt. Un reset li cancella.
• Integrazioni e credenziali: token API, chiavi di autenticazione con servizi esterni (email, Telegram, CRM, database clienti). Non è solo "ripristina dal backup" — devi ripristinare anche il collegamento.
• Log di esecuzione e audit trail: se la pipeline smette non sai a che punto si era interrotta, se ha mandato mail duplicate, se ha creato record inconsistenti.
• Configurazione dello stato della logica: quale agente è attivo, quali steps di una pipeline sono completati, quale risorsa esterna è in timeout.

Un database PostgreSQL in backup è una cosa. Una pipeline RAG dove l'embedding index è corrotto, i prompt sono versioni vecchie, e non sai quale richiesta era a metà è un'altra.

# Le tre dimensioni di un DR credibile

1. Backup dei dati persistenti

È la parte più ovvia, ma non è scontata come sembra:

• Database di stato: conversazioni, risultati processati, metadati delle automazioni. Backup giornaliero o orario a seconda della criticità. Tienine almeno 2-3 copie in zone geografiche diverse se il downtime costa soldi.
• Vector database / embedding store: Pinecone, Weaviate, Milvus, Chroma. Se usi il cloud, il provider fa backup, ma verifica la frequenza e il tempo di ripristino nei loro SLA. Se self-hosted, è responsabilità tua. Uno snapshot al giorno è il minimo.
• File storage: documenti caricati dagli utenti, output generati, log di audit. Se usi S3 o simile, abilita il versioning e una regola di retention.
• Configurazioni e prompt versioning: i tuoi prompt, le istruzioni degli agenti, i parametri di temperatura/top_k. Custodisci tutto in Git. Non in un file su desktop.

2. Tracciamento dello stato di esecuzione

Qui è dove la maggior parte dei progetti fallisce. Una pipeline automatizzata può interrompersi a metà:

• Ha processato il messaggio dell'utente e generato una risposta LLM, ma non ha salvato il risultato in database.
• Ha mandato un'email ma non ha aggiornato il flag "email inviata" nel record.
• Ha downloadato un file, l'ha processato, ma poi la connessione al CRM è andata giù prima di salvare.

Senza un log di esecuzione dettagliato (idealmente idempotente), al ripristino non sai se ripetere l'ultima operazione o se era già stata completata.

La soluzione è logged checkpoints:

1. Ogni step critico scrive un checkpoint con timestamp, ID della richiesta, esito.
2. Se il sistema crasha, al riavvio legge l'ultimo checkpoint e sa da dove ricominciare.
3. Se uno step è idempotente (es. "scrivi questo record se non esiste già"), ripeterlo non causa danni.

Strumenti come Temporal, Airflow, o anche semplici state machine salvate in database possono gestire questa parte. Ma va progettata da subito, non aggiunta dopo.

3. Piano di recovery operativo

Il disaster recovery non è solo tecnica. È anche procedura:

• RTO (Recovery Time Objective): quanto tempo puoi stare down? Per un bot Telegram non critico, 2-3 ore vanno bene. Per un'automazione che processa ordini, anche 15 minuti sono troppi.
• RPO (Recovery Point Objective): quanti dati perdi al massimo? Se perdi le ultime 6 ore di conversazioni è accettabile? O devi scendere a 15 minuti?
• Procedura di failover: se il server principale cade, come attivi quello di backup? È automatico o manuale? Chi lo sa fare alle 3 di notte?
• Verifica dei dati ripristinati: dopo il recovery, prima di mettere il sistema online, qualcuno controlla che non ci siano inconsistenze? Un prompt che ha una versione vecchia di 3 mesi? Un agente che ha configurazione parziale?

# Strategie concrete per diversi scenari

Scenario	RTO	RPO	Approccio consigliato
Bot Telegram non critico (intrattenimento, informazioni)	2-4 ore	24 ore	Backup database giornaliero, replica su storage secondario (S3), recovery manuale. Uptime non è critica, ma la continuità dei dati sì.
Automazione CRM / email (business process)	30 minuti	1 ora	Replicazione database in tempo reale (PostgreSQL streaming replication), vector DB con snapshot orario, checkpoint di esecuzione per ogni operazione critica, failover semi-automatico.
Sistema di elaborazione ordini / pagamenti	5-15 minuti	5 minuti	Active-active su due zone di disponibilità, database distribuito (Postgres multi-master o cluster), vector DB sincronizzato, queue (RabbitMQ, Redis) per le operazioni in-flight, monitoring in tempo reale con alert.
Pipeline di analisi batch notturna (non real-time)	24 ore	24 ore	Backup giornaliero post-elaborazione, checkpoint tra i step, log di esecuzione. Se fallisce, riparte dal checkpoint precedente la notte dopo.

La colonna della destra non è una lista di tool, è una descrizione della robustezza che serve. I tool specifici dipendono dal tuo stack.

# Cosa include un DR plan realistico

Documentazione (spesso dimenticata)

• Dove sono i backup? Cloud, on-prem, quanti giorni di retention?
• Come si ripristina il database? Quali comandi, quale ordine?
• Come si ripristinano le credenziali? (Vault, .env file, AWS Secrets Manager?)
• Come si verifica che tutto sia online? Chi fa il test, quand'è programmato?
• Chi è il responsabile? Chi contatti alle 3 di notte se il sistema è down?

Test periodici

• Almeno una volta al trimestre: simula un crash, ripristina da backup, verifica che il sistema sia operativo.
• Tempo massimo per il ripristino: va registrato e confrontato con l'RTO. Se impiega 3 ore ma il tuo RTO è 30 minuti, hai un problema.
• Consistency check: dopo il ripristino, verifica che non ci siano record duplicati, conversazioni incomplete, credenziali scadute.

Monitoraggio e alerting

• Logs di esecuzione: centralizzati (ELK, Datadog, Grafana Loki), non solo nel filesystem della VM.
• Alerting su errori critici: se uno step della pipeline fallisce, qualcuno lo sa entro 5 minuti.
• Health check periodici: ogni ora almeno un "test" che la pipeline è ancora reattiva.

# Quando il DR NON serve (davvero)

Essere onesti: non sempre il DR completo è proporzionato al rischio.

Un bot Telegram che legge il meteo e lo riscrive in formato buffo non ha bisogno di active-active replica. Perdi 24 ore? È spiacevole ma non costa nulla. In quel caso: backup giornaliero, recovery manuale entro 24 ore, test annuale. Basta.

Però se quell'automazione è collegata a un sistema che elabora ordini, genera fatture o interagisce con banche, ogni ora di downtime costa. Lì il DR non è opzionale.

La domanda giusta non è "quanto DR mi serve in assoluto", ma "quanta perdita di uptime e quanti dati persi l'azienda tollera?" Da lì definisci RTO e RPO, e da lì scegli l'infrastruttura.

# Checklist finale

• Database principale: ha backup? Dove? Quanta retention? Testato il ripristino?
• Vector DB / embedding store: ha backup? Se è gestito dal provider, conosci il loro SLA?
• Configurazioni e prompt: sono in Git con history? O solo su un file locale?
• Credenziali e secret: sono gestiti da un Vault (AWS Secrets, Vault di HashiCorp, etc.) o sparse in .env file?
• Log di esecuzione: sono centralizzati o solo nel filesystem?
• Checkpoint di stato: ogni operazione critica sa da dove ricominciare in caso di crash?
• RTO e RPO: sono documentati e concordati con chi usa il sistema?
• Test di recovery: quando è stato l'ultimo? Quanto tempo ha impiegato? È stato documentato?
• Responsabile DR: chi è? Come lo contatti se il sistema è down?