Caso di studio sul ripristino da backup: 6 ore indietro
Pubblicato il 10 luglio 2026
Alle 02:14 UTC, la vetrina ha smesso di scrivere gli ordini nel database. Alle 02:19, il sito continuava ancora a servire pagine in cache, ma il checkout era già diventato una finzione. Questo caso di studio sul ripristino da backup segue ciò che è accaduto dopo su un VPS di produzione per una piccola attività di e-commerce, ciò che abbiamo ripristinato, ciò che non abbiamo ripristinato alla cieca e perché il servizio era di nuovo stabile prima dell'alba.
Il cliente eseguiva uno stack piuttosto standard per un negozio online in crescita - Nginx, PHP-FPM, MariaDB, Redis e un pannello di controllo usato da due membri del personale non sysadmin. Il traffico non era enorme, ma il tempismo era doloroso. Una campagna promozionale aveva aumentato il volume degli ordini, le scritture sul database avevano raggiunto il picco e un problema di storage a livello di filesystem ha iniziato a corrompere le tabelle attive del database. Non drammatico in stile Hollywood, ma abbastanza serio da far sì che ogni minuto contasse.
Il primo compito non era il ripristino. Il primo compito era fermare la propagazione del danno. Abbiamo messo l'applicazione in modalità manutenzione, preservato lo stato corrente del disco per la revisione e verificato se replica, snapshot o dump logici ci dessero il punto di ripristino più pulito. Questo conta più di quanto la gente voglia ammettere. Un ripristino rapido è una buona cosa. Un ripristino rapido verso dati danneggiati è solo una delusione rapida.
Che cosa è fallito e come lo abbiamo capito
A quel punto i log raccontavano la stessa storia. MariaDB ha iniziato a segnalare errori di checksum delle pagine InnoDB, seguiti dal crash delle tabelle degli ordini e delle sessioni con carico elevato di scrittura. L'hypervisor stesso era in salute. CPU, RAM e comportamento della rete sono rimasti normali. Questo ha ristretto l'evento, allontanandolo da un'interruzione ampia della piattaforma e indirizzandolo verso l'integrità dello storage a livello guest.
Abbiamo verificato tre cose prima di toccare i backup. Primo, se il problema fosse isolato a un piccolo insieme di tabelle e potesse essere riparato in loco. Secondo, se i backup recenti fossero validi e montabili. Terzo, se eventuali transazioni completate dopo l'ultimo backup sicuramente valido potessero essere ricostruite dai log dell'applicazione, dalle conferme email o dai record del gateway di pagamento.
Quel terzo controllo viene spesso saltato. Non dovrebbe. Ripristinare un backup non equivale all'intero recupero. Alle aziende interessano gli ordini mancanti, i record dei clienti e lo stato delle fatture, non solo il fatto che MySQL si riavvii.
Il percorso di ripristino che abbiamo scelto
Questo caso di studio sul ripristino da backup è utile perché l'opzione più ovvia non era l'opzione migliore. Avevamo tre percorsi candidati.
Un rollback completo dello snapshot della VM sarebbe stato il più rapido in termini di numero di clic, ma avrebbe anche scartato diverse ore di modifiche legittime ai contenuti, aggiornamenti dei plugin e modifiche agli account dei clienti. Riparare le tabelle in loco comportava troppo rischio perché la corruzione aveva già colpito i dati transazionali principali. La strada migliore era un ripristino a livello di file e di database in una nuova istanza, seguito da una riconciliazione selettiva dei dati.
Quindi abbiamo prima predisposto un ambiente di ripristino pulito. Stessa dimensione del VPS, stessa famiglia di OS, stessa versione del pannello, stesso ramo PHP. Ricostruire in un'istanza parallela dà respiro. Protegge anche il sistema originale per la revisione forense, il che è utile se il cliente ha bisogno di comprendere la causa radice o di verificare che il problema non sia stato causato dal comportamento dell'applicazione.
Abbiamo prelevato l'ultimo backup automatico riuscito delle 23:00 UTC. Poi lo abbiamo testato prima del cutover. Sembra una cosa basilare, ma molti team scoprono i problemi dei backup solo nell'ora peggiore possibile. L'archivio è stato montato correttamente, i checksum corrispondevano, l'importazione del database è stata completata senza errori e l'applicazione si è avviata in isolamento. Bene. La calma inizia da lì.
Ripristinare il servizio senza creare nuovi problemi
Il recupero ha avuto quattro fasi. Primo, l'infrastruttura. Abbiamo ricostruito lo stack web, applicato gli aggiornamenti di sistema già approvati e allineato le versioni runtime affinché l'applicazione non fallisse a causa di un inatteso disallineamento delle dipendenze.
Secondo, i dati. Il ripristino del database è stato completato in 11 minuti. I file web sono stati ripristinati in meno di 4 minuti. Le risorse multimediali erano intatte, il che ha risparmiato al cliente immagini di prodotto rotte e riquadri del browser infuriati. Redis non è stato ripristinato dal backup perché i dati in cache sono eliminabili per definizione. Riportare una cache obsoleta in un ambiente fresco è uno di quei piccoli errori che più tardi creano un gran caos.
Terzo, la validazione. Abbiamo controllato login dell'applicazione, flusso di checkout, scritture admin, esecuzione di cron, validità SSL, posta in uscita e comportamento delle callback del gateway di pagamento. Abbiamo anche confrontato il numero di record tra ordini, clienti e tabelle del catalogo con le curve di crescita attese della settimana precedente. I numeri non devono essere poesia perfetta, ma non dovrebbero sembrare strani.
Quarto, la riconciliazione. Tra le 23:00 UTC e le 02:14 UTC, era stato elaborato un piccolo numero di pagamenti andati a buon fine. Quei record non esistevano nel database ripristinato perché si erano verificati dopo il punto di backup. Li abbiamo ricostruiti dalle conferme del fornitore di pagamenti, dalle notifiche email degli ordini e dai log di accesso web. È qui che un operatore esperto evita molto dolore al business. Un ripristino tecnicamente riuscito che perde ordini pagati non è davvero un successo.
Alle 03:41 UTC, l'applicazione era disponibile per la revisione interna del cliente. Alle 04:06 UTC, DNS e instradamento edge hanno riportato il traffico di produzione verso l'istanza recuperata. L'interruzione del checkout lato cliente è stata inferiore a due ore, mentre l'accesso in lettura alla maggior parte del sito è rimasto disponibile per gran parte dell'incidente.
Che cosa ha reso rapido il recupero
Non è stata fortuna e non è stato un singolo pulsante magico di backup. La velocità è derivata dalla preparazione e dalla riduzione delle decisioni durante l'incidente.
Il cliente disponeva già di backup pianificati automatici con conservazione, comportamento del server monitorato e un percorso di supporto che non svaniva nel silenzio dei ticket. Questo ha cambiato l'andamento della notte. Non stavamo discutendo se esistesse un backup. Stavamo scegliendo il punto di ripristino più sicuro e lo stavamo validando.
Anche la coerenza dell'ambiente contava. Poiché lo stack di hosting era standardizzato, non abbiamo speso 45 minuti di nervosismo a scoprire che l'app ripristinata richiedeva una vecchia estensione PHP o una libreria di sistema mancante. Le persone spesso sottovalutano quanto tempo di recupero venga bruciato dalla deriva della configurazione.
C'è stato anche un vantaggio meno visibile - separare ciò che ha stato da ciò che è eliminabile. Contenuti del database, media caricati, configurazione e risorse SSL sono stati trattati con attenzione. Cache, file temporanei e sessioni generate sono stati ricostruiti in modo pulito. Questo rende il recupero più snello ed evita di trascinare vecchio rumore in un nuovo avvio.
Che cosa insegna questo caso di studio sul ripristino da backup
La lezione principale non è semplicemente fare il backup del server. La maggior parte delle aziende conosce già questa frase. La lezione più difficile è progettare il recupero attorno alla funzione aziendale, non solo agli oggetti dell'infrastruttura.
Uno snapshot della VM è utile, ma può essere troppo grossolano. Un dump del database è utile, ma non basta se i file caricati sono separati. Un backup del pannello di controllo è comodo, ma anche la comodità dovrebbe essere testata. La giusta strategia di backup dipende da come si comporta l'applicazione, da quanto spesso cambiano i dati e da quale quantità di perdita sia effettivamente accettabile.
Per un sito e-commerce, le immagini dei prodotti possono di solito tollerare punti di ripristino leggermente più vecchi rispetto ai record degli ordini. Per un'applicazione SaaS, lo stato del database dei clienti può contare più del contenuto del filesystem locale. Per un'agenzia digitale che ospita più siti clienti su un unico server, l'isolamento diventa critico perché un sito rumoroso non dovrebbe trasformare il recupero in un mal di testa per l'intero rack.
Anche i test meritano più rispetto. I backup sono promesse finché non vengono ripristinati. Dopo essere stati ripristinati, diventano evidenza. La differenza costa cara.
Che cosa è cambiato dopo l'incidente
Non abbiamo trattato il recupero come il traguardo finale. Dopo la stabilizzazione del servizio, abbiamo esaminato il comportamento dello storage, la salute del filesystem, i controlli di integrità del database e la tempistica della policy di backup. La causa tecnica immediata indicava un'incoerenza del disco a livello guest sotto pressione di scrittura, ma la domanda più ampia era come ridurre il blast radius la prossima volta.
La frequenza dei backup è stata regolata per il livello database, così da ridurre l'esposizione del punto di ripristino durante le campagne. Le soglie di allerta per l'attesa I/O e i pattern di errore del database sono state ristrette. Il cliente è anche passato da una mentalità di singolo ripristino a una stratificata - backup automatici, routine di ripristino verificate e una gestione più chiara della riconciliazione transazionale.
È qui che il supporto operativo gestito dimostra il suo valore. Non perché gli incidenti non accadano mai, ma perché quando accadono, qualcuno sa già dove guardare per prima cosa e cosa non rompere mentre lo si sistema. Quella piccola differenza è spesso l'intera differenza.
Se esegui workload che generano ricavi, la domanda utile non è se hai dei backup. La domanda utile è se, alle 2 del mattino, puoi ripristinare i dati giusti nel posto giusto, verificarli rapidamente e rendere conto di ciò che è successo dopo l'esecuzione del backup. Se la risposta è incerta, il sistema sta ancora chiedendo attenzione. Meglio rispondere in un tranquillo pomeriggio che durante un guasto del checkout.
Andres Saar Customer Care Engineer