Vai al contenuto

Backup, downtime, ripristino: cosa succede il giorno che la tua web app si rompe

Il giorno che la tua web app si rompe, la differenza tra due ore di stop e due giorni di caos la decide quello che hai preparato prima. Non il fornitore che chiami nel panico. Non la fortuna.

Il downtime è il periodo in cui un’applicazione non è raggiungibile o non funziona. Quando succede, hai bisogno di tre cose già pronte: un backup recente, un piano di ripristino testato e qualcuno che sa dove mettere le mani.

Se hai questi tre elementi, il guasto diventa un incidente gestibile. Se non li hai, ogni minuto lavora contro di te: ordini persi, clienti bloccati, staff fermo. La resilienza di una Web App non si costruisce durante l’emergenza. Si costruisce nei mesi tranquilli, quando nessuno ci pensa.

Perché una web app si rompe, e non è una questione di “se”

Ogni applicazione prima o poi si ferma. Cambia solo quando e quanto. Un aggiornamento andato male, un server che va giù, un database corrotto, un errore umano in produzione: le cause sono molte e quasi tutte prevedibili.

Il problema non è il guasto in sé. È non averlo messo in conto. Molte aziende trattano la propria applicazione come un elettrodomestico: funziona, quindi non ci si pensa. Poi arriva il giorno storto e non esiste un piano.

Io parto sempre dal presupposto opposto. Do per scontato che qualcosa si romperà e progetto di conseguenza. Questo cambia le decisioni tecniche fin dall’inizio, non dopo il primo disastro.

Cosa serve avere pronto prima del guasto

Un piano di continuità è l’insieme di misure che permettono di ripristinare un servizio dopo un’interruzione, entro tempi definiti. Senza questo piano, il ripristino diventa improvvisazione. E l’improvvisazione, sotto pressione, costa cara.

Gli elementi minimi che verifico su ogni progetto:

  • Backup automatici e recenti. Il backup è una copia dei dati e del sistema salvata separatamente. Deve essere frequente, non settimanale.
  • Backup testati davvero. Un backup che non hai mai ripristinato non è un backup: è una speranza. Va provato periodicamente.
  • RTO e RPO definiti. L’RTO è il tempo massimo accettabile per tornare operativi. L’RPO è la quantità massima di dati che puoi permetterti di perdere.
  • Ambiente di staging. Uno spazio separato dove testare aggiornamenti prima di portarli in produzione.
  • Contatti e responsabilità chiare. Chi chiami alle 22 di un venerdì? Deve essere scritto, non intuito.

Quando questi cinque punti esistono e sono aggiornati, un guasto grave si gestisce con calma. Quando mancano, la stessa situazione diventa una notte in bianco e un danno che si moltiplica ora dopo ora. La preparazione non elimina i problemi. Riduce il loro impatto a una frazione.

Quanto downtime posso permettermi davvero?

Dipende da cosa fa la tua applicazione, e la risposta va scritta in numeri prima del guasto, non stimata durante. Un gestionale interno tollera qualche ora. Un e-commerce che vende ogni minuto, no.

Il modo corretto è ragionare sul costo del fermo. Quanto perdo per ogni ora offline, tra vendite mancate, staff bloccato e clienti che vanno altrove? Questo numero definisce quanto ha senso investire in ridondanza e velocità di ripristino.

Non tutte le applicazioni meritano lo stesso livello di protezione. Sovradimensionare costa. Sottodimensionare costa di più, ma solo il giorno sbagliato. Il mio lavoro è trovare la soglia giusta per il tuo caso specifico, senza vendere infrastruttura che non ti serve.

Come funziona un ripristino fatto bene

Un ripristino ben eseguito segue una sequenza già decisa: si isola il problema, si valuta il danno, si sceglie il punto di ripristino, si torna operativi, si verifica. Nessun passaggio viene inventato sul momento.

La parte che le aziende sottovalutano è la verifica. Rimettere online un sistema non basta: bisogna confermare che i dati siano integri e che le funzioni critiche rispondano. Un ripristino frettoloso può reintrodurre lo stesso errore che ha causato il guasto.

Per questo tengo separati l’ambiente di produzione e quello di test. Ripristino prima in un ambiente controllato, controllo che tutto torni, poi porto la soluzione dove serve. Meno velocità apparente, molto meno rischio di peggiorare la situazione.

Domande ricorrenti su backup e continuità operativa

Ogni quanto dovrei fare il backup della mia web app?

Dipende da quanti dati puoi permetterti di perdere. Se la tua applicazione registra transazioni continue, un backup giornaliero non basta: perderesti fino a un giorno di lavoro. In quel caso servono backup più frequenti o soluzioni in continuo. Se invece i dati cambiano poco, una frequenza giornaliera è ragionevole. Il parametro che decide è l’RPO, cioè la quantità massima di dati che accetti di perdere.

Il mio hosting fa già i backup. Non basta?

Spesso no. Molti provider fanno backup pensati per proteggere la propria infrastruttura, non per farti ripristinare in fretta. Non sempre puoi accedervi in autonomia, non sempre coprono la finestra temporale che ti serve, e quasi mai li hai testati. Un backup che non hai mai provato a ripristinare è un rischio, non una garanzia. Ti consiglio sempre di avere una strategia di backup indipendente dal fornitore.

Quanto costa mettere in sicurezza un’applicazione già esistente?

Meno di quanto costi un fermo grave, quasi sempre. L’investimento dipende dal livello di protezione che ti serve, che a sua volta dipende dal costo del tuo downtime. Un intervento base su backup e procedure di ripristino ha un costo contenuto. La ridondanza completa dell’infrastruttura costa di più e non serve a tutti. Definisco la soglia giusta insieme a te, partendo dal tuo caso reale.

Cosa succede se scopro il problema solo al mattino?

Se hai backup automatici e un piano scritto, la scoperta tardiva pesa poco: recuperi dall’ultimo punto valido e riparti. Se non li hai, ogni ora trascorsa amplia il danno e complica la diagnosi. La differenza non la fa la rapidità con cui te ne accorgi, ma quanto avevi preparato prima. Ecco perché lavoro sulla prevenzione più che sulla reazione.

Devo rifare tutta l’applicazione per renderla più solida?

Quasi mai. Nella maggior parte dei casi intervengo sull’esistente: sistemo i backup, definisco RTO e RPO, aggiungo un ambiente di test, scrivo le procedure di ripristino. Sono interventi mirati che aumentano la resilienza senza riscrivere il codice. Una ricostruzione completa ha senso solo quando l’applicazione ha problemi strutturali profondi, e in quel caso te lo dico chiaramente.

Parliamo di cosa succede alla tua applicazione il giorno storto

Se gestisci un’applicazione su cui gira parte del tuo lavoro, la domanda giusta non è se si romperà. È cosa succede quando accade.

Posso guardare la tua situazione attuale e dirti dove sei esposto: backup, tempi di ripristino, ambiente di test, procedure. Senza allarmismi e senza vendere infrastruttura che non ti serve. Un primo confronto serve esattamente a questo: capire se il livello di protezione che hai oggi è adeguato a quanto costerebbe un fermo.

Se vuoi fare questa verifica, scrivimi dalla pagina contatti e la organizziamo.

Articoli correlati