Ogni sito WordPress dichiara di avere dei backup. La maggior parte di quei backup non lo è davvero. Sono cartelle di file compressi che stanno sullo stesso server del sito in produzione, mai testati, spesso incompleti e silenziosamente destinati a fallire proprio nel momento in cui servono di più.
Un backup che non è mai stato ripristinato non è un backup: è una speranza. Un backup archiviato sulla stessa macchina del sito in produzione non è un backup: è una copia. Dopo abbastanza storie dell’orrore in cui un’azienda credeva di avere dei backup e ha scoperto troppo tardi di non averli, i criteri di ciò che conta come backup reale sono più chiari che mai.
I quattro tratti di un backup reale
- Esterno. Archiviato in un luogo geograficamente e infrastrutturalmente separato dal sito in produzione. Se il server in produzione va a fuoco, il backup deve sopravvivere. «Salvato in un’altra cartella sullo stesso host» non è esterno. Archiviato su S3, Google Cloud, Dropbox o presso un fornitore del tutto diverso, lo è.
- Completo. Include sia il database sia i file (caricamenti, temi, plugin). I backup del solo database possono ripristinare i contenuti ma non il sito visivo. I backup dei soli file possono ripristinare l’aspetto ma non gli articoli. Un backup reale contiene entrambi, presi nello stesso momento.
- Recente. Giornaliero per un sito che si aggiorna di frequente. Settimanale è il minimo per un sito vetrina. Un backup di tre mesi fa è tecnicamente un backup, ma significa perdere ogni interazione con i clienti da allora.
- Testato. Il tratto più spesso saltato. Un backup che non è mai stato ripristinato non ha mai dimostrato di funzionare. Testa i ripristini almeno ogni trimestre. Porta il backup in un ambiente di staging e conferma che il sito si avvii correttamente. La prima volta che scopri che il tuo backup è corrotto non dovrebbe essere il giorno in cui ti serve.
La regola 3-2-1, applicata a WordPress
La regola 3-2-1 dei backup del settore IT si applica in modo pulito ai siti WordPress. Tre copie dei dati (il sito in produzione più due backup). Due tipi di supporto diversi (archiviazione su server più archiviazione su cloud). Una copia esterna (in una posizione del tutto diversa).
Per un tipico sito WordPress di un’azienda australiana, potrebbe apparire così: sito in produzione su hosting australiano gestito, backup giornaliero su UpdraftPlus su Google Drive, backup settimanale su Amazon S3 in un’altra regione. Tre copie, due fornitori, una del tutto esterna.
I fallimenti di backup più comuni
- Backup solo sull’host. Il backup dell’host va bene finché l’host non ha un disservizio o il tuo account non viene sospeso. Molte aziende scoprono, nel mezzo di una disputa con l’hosting, che il backup che credevano di avere è bloccato dietro un account a cui non possono accedere.
- Il plugin ha fallito in silenzio. La pianificazione giornaliera del plugin di backup ha smesso di funzionare sei mesi fa. Nessuno se n’è accorto perché nessuno controllava. Il backup è vecchio di sei mesi prima che qualcuno se ne renda conto.
- Mancano tabelle del database. Un backup mal configurato che esclude le tabelle di WooCommerce o quelle di plugin personalizzati. Il backup sembra un backup, ma gli mancano i dati più importanti.
- Il backup è troppo grande da ripristinare. Il backup è stato completato, ma il file è così grande che ripristinarlo entro i limiti di timeout PHP dell’host è impossibile. I dati sono conservati, ma non davvero accessibili senza un intervento manuale.
Cosa comporta davvero un ripristino
Un vero test di ripristino, dall’inizio alla fine, richiede circa 30 minuti. Avvia un’installazione WordPress pulita su un URL di staging. Scarica il backup più recente. Ripristinalo. Percorri il sito, conferma che la home page si carichi, controlla che ci sia un articolo recente, invia il modulo di contatto, prova una transazione se c’è e-commerce. Se tutto questo funziona, il backup è reale.
La prima volta che la maggior parte delle aziende fa questo, scopre almeno un problema nel proprio processo di backup. La seconda volta, i problemi sono di solito risolti. La quarta volta, il team inizia a fidarsi dei backup, e quella fiducia è meritata.
Un’abitudine trimestrale, non una configurazione una tantum
L’igiene dei backup non è un progetto una tantum. È un’abitudine trimestrale. Ogni tre mesi ripristina il backup più recente in staging e conferma che il sito si avvii pulito. Ogni sei mesi verifica le destinazioni dei backup per assicurarti che l’archiviazione non sia piena e che le credenziali non siano scadute.
Questa è una delle parti della manutenzione di WordPress meno entusiasmanti e più importanti. I piani di manutenzione di Defyn includono il test di ripristino trimestrale come voce standard della checklist, uno dei motivi per cui i clienti a contratto non subiscono quasi mai una perdita di dati catastrofica. I backup sono stati testati. Funzionano davvero.
