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.
