Ogni sistema di backup che abbia mai tradito un cliente segnalava successo tutti i giorni, fino al giorno in cui è servito. Il rapporto dice che il file è stato scritto. Non dice che il file si possa leggere, che contenga quello che credi, né che ripristinarlo produca un sito funzionante.
Prova il ripristino, non il backup
- Prendi l'archivio più recente — Non uno creato apposta. Il punto è mettere alla prova il processo che gira senza nessuno davanti.
- Ripristinalo da un'altra parte — Un sottodominio, un secondo VPS, un container in locale. Mai sopra il sito in produzione.
- Apri il sito ripristinato — Accedi. Carica una pagina che legge il database. Controlla che ci sia un file caricato di recente.
- Annota la data del contenuto più recente — Quello è il tuo vero punto di ripristino, e spesso è più vecchio di quanto lasci credere il calendario dei backup.
Che cosa rivela di solito un ripristino
- Il database c'è ma i file caricati no — il backup copriva l'uno e non gli altri.
- Si ripristina ma non parte — un file di configurazione con i percorsi o le credenziali del vecchio server.
- L'archivio è troncato — il disco si è riempito durante il backup e nessuno ha guardato il codice di uscita.
- È cifrato e nessuno ha la chiave — la chiave stava sul server che è morto.
Un backup sullo stesso disco del sito non è un backup. Protegge da un errore, non dal disco, dal server o dall'account. Almeno una copia vive altrove.
Ogni quanto
La domanda onesta non è ogni quanto fare il backup, ma quanto lavoro sei disposto a rifare. Giornaliero vuol dire fino a un giorno di ordini perduto. Se questo è inaccettabile, giornaliero è il calendario sbagliato, quale che sia il costo dell'alternativa.
Metti in calendario una prova di ripristino, ogni trimestre. È l'unica prova che dimostri qualcosa, ed è l'unica che non fa nessuno.