Contenuti
Era un piccolo progetto.
Il sito non era ancora in produzione e il lavoro assegnato non sembrava particolarmente complicato: una piccola manutenzione prima di consegnare il progetto.
Per un ragazzo che era entrato da poco in agenzia era anche un’occasione per iniziare a prendere confidenza con il sito.
Prima di cominciare fece quello che gli era stato insegnato.
Un backup.
La copia dei file venne eseguita e il lavoro iniziò.
Dopo qualche modifica, però, qualcosa non andò come previsto.
Il problema non riguardava i file.
Riguardava il database.
E a quel punto arrivò la domanda:
“Abbiamo un backup?”
Sì.
Il backup c’era.
Ma non era il backup del database.
La copia c’era. Il problema era altrove
Il ragazzo aveva fatto una copia dei file del sito prima di iniziare.
Era quindi convinto di avere una possibilità per tornare indietro.
Il problema è che un sito non è fatto soltanto di file.
Una parte importante delle informazioni può trovarsi nel database: configurazioni, contenuti, utenti e altri dati utilizzati dall’applicazione.
L’intervento aveva modificato proprio una di quelle informazioni.
La copia dei file non permetteva quindi di riportare il database alla situazione precedente.
Non era un backup sbagliato.
Era una copia che proteggeva una parte diversa del sistema rispetto a quella che era stata modificata.
Il problema non era irrecuperabile
Il database non era stato perso definitivamente.
Non era successo un disastro.
Ma il lavoro si complicò.
Bisognava capire esattamente cosa era stato modificato, ricostruire la situazione precedente e verificare che il sito tornasse a funzionare correttamente.
Quello che doveva essere un piccolo intervento di manutenzione diventò un’attività molto più lunga.
Il tempo previsto per la manutenzione non era più sufficiente.
E soprattutto era diventato necessario fare un lavoro che, con una strategia di ripristino adeguata, probabilmente sarebbe stato molto più semplice.
“Ho fatto il backup” non è una risposta sufficiente
Questa situazione mostra un errore molto comune quando si parla di backup.
La domanda:
“Hai fatto il backup?”
sembra avere una risposta semplice.
Sì oppure no.
Ma prima di un cambiamento la domanda dovrebbe essere un’altra:
“Che cosa sto per modificare e da quale situazione devo poter tornare indietro?”
Se sto modificando un file, una copia di quel file potrebbe essere sufficiente.
Se sto intervenendo sul database, devo poter recuperare il database.
Se l’intervento coinvolge più componenti, la strategia di ripristino deve tenere conto di tutte le parti coinvolte.
Non esiste quindi una copia che protegge automaticamente da qualsiasi intervento.
Non sempre serve fare una copia di tutto
Questo non significa che prima di ogni piccola modifica sia necessario fare un backup completo del server.
Sarebbe una conclusione altrettanto semplicistica.
Una modifica limitata può richiedere una protezione limitata.
Un intervento più complesso può richiedere una copia molto più ampia.
La questione non è fare sempre la copia più grande possibile.
È fare una copia che permetta realmente di tornare alla situazione precedente se qualcosa va storto.
La lezione
Il ragazzo aveva fatto il backup.
Aveva cercato di lavorare con prudenza.
Ma aveva protetto una parte diversa da quella che stava per modificare.
Il risultato non è stato la perdita del sito.
È stato qualcosa di molto più ordinario: tempo perso per rimediare a una situazione che avrebbe potuto essere preparata meglio.
E proprio per questo il caso è interessante.
Perché il backup non dovrebbe essere un’azione automatica da eseguire prima di una manutenzione.
Dovrebbe essere collegato a ciò che stiamo per cambiare.
La domanda non è soltanto:
“Ho fatto il backup?”
Ma:
“Se questa modifica va male, ho davvero un modo per tornare indietro?”
È una differenza piccola nella domanda.
Ma può essere molto grande quando il problema arriva.
