Backup del sito e piano di disaster recovery
Cosa succede se il suo sito viene violato, il server si guasta o una pagina viene cancellata per errore? Piano di backup e test di ripristino.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Un piano di backup deve rispondere a tre domande: con quale frequenza viene fatto il backup, è conservato separatamente dal server in produzione, e un ripristino è stato davvero provato. Se manca anche una sola risposta, il backup su cui contate è solo un'ipotesi, fino al momento esatto in cui serve davvero.
Il disaster recovery suona come qualcosa che riguarda solo le grandi aziende, ma è altrettanto reale per una piccola impresa. Se il sistema di prenotazione di una catena di centri benessere si rompe durante un aggiornamento, o il database di un negozio online viene cancellato per errore, il tempo necessario a recuperare si trasforma direttamente in fatturato perso.
Cosa dovrebbe coprire davvero un backup
Il backup di un sito ha due parti: i file, tema, plugin, immagini caricate, e il database, prodotti, ordini, account utente, articoli del blog. Se le due non vengono salvate insieme, un ripristino a cui ne manca una lascia metà sito funzionante e l'altra metà vuota.
In un negozio online il database cambia continuamente, può servire un backup giornaliero o persino orario; per un sito aziendale vetrina, un backup settimanale in genere basta. La frequenza giusta segue quanto spesso il sito cambia davvero.
Dove dovrebbe essere conservato il backup
Tenere il backup sullo stesso server del sito in produzione è l'errore più comune. Se il server diventa completamente irraggiungibile, il backup che vi risiede scompare nello stesso momento. Un backup dovrebbe esistere anche in un luogo completamente separato, un altro server, un servizio di archiviazione cloud, o l'archivio proprio dell'azienda.
Non esiste un'unica risposta corretta a quante copie e dove; dipende dalla dimensione dell'azienda. La regola che non cambia è questa: almeno una copia deve stare in un luogo totalmente indipendente dal server che ospita il sito.
Perché il test di ripristino viene saltato, e perché non dovrebbe esserlo
La maggior parte delle aziende sa di fare backup, ma non ha mai davvero provato a ripristinarne uno. Un file di backup corrotto, una tabella di database mancante o una versione di plugin incompatibile emergono solo quando si tenta un ripristino, e raramente in un momento comodo.
Un test di ripristino può essere eseguito in un ambiente di test separato, senza toccare il sito in produzione. Fatto poche volte l'anno, trasforma ore di incertezza in una crisi reale in pochi minuti.
Cosa dovrebbe contenere davvero un piano di disaster recovery
A differenza di un backup, un piano di disaster recovery mette per iscritto chi fa cosa quando qualcosa va storto. Può stare in una sola pagina, ma deve rispondere a tre domande.
- Se il sito diventa completamente irraggiungibile, chi viene chiamato nei primi 30 minuti, e chi ha accesso al pannello di hosting
- Dove si trova l'ultimo backup funzionante, e chi può accedervi
- Quale messaggio dovrebbero vedere i clienti, o una pagina di vendita attiva, mentre il ripristino è in corso
Quali eventi attivano questo piano
Il disaster recovery non riguarda solo i guasti del server. Un sito che si rompe dopo un aggiornamento, un conflitto tra plugin, una pagina cancellata per errore, un tentativo di violazione, o un'interruzione presso lo stesso fornitore di hosting, tutto questo richiede lo stesso piano.
Se la pagina catalogo prodotti di un produttore di pavimenti si rompe durante un aggiornamento, non è un disastro su larga scala, ma lo stesso piano deve funzionare anche su piccola scala: a quale backup tornare, chi lo approva, e in quanto tempo.
Errori frequenti nei backup
L'errore più frequente è salvare solo a livello di file dimenticando il database. Se il backup settimanale di un sito industriale copre solo tema e immagini, un modulo d'ordine o un contatto può andare perso al momento del ripristino.
Il secondo errore è che nessuno legge davvero la notifica di backup. Uno strumento automatico può inviare un'email ogni notte, ma se resta non letta per settimane, un backup che fallisce silenziosamente passa inosservato altrettanto a lungo.
Il terzo è affidarsi interamente al sistema proprio del fornitore di hosting senza alcuna copia altrove. Se il sito di una catena di centri benessere dipende da un unico backup conservato sul server del fornitore, una controversia o un problema di account con quel fornitore può portarsi via anche l'accesso al backup.
Come si applica il disaster recovery, passo dopo passo
Nel momento di un'interruzione, la prima cosa da fare, senza farsi prendere dal panico, è capire l'ampiezza del problema: è coinvolta solo una pagina, o il sito è completamente irraggiungibile?
- Determini l'ampiezza del problema: una sola pagina, tutto il sito, o solo la posta è coinvolta
- Trovi l'ultimo backup noto funzionante e ne annoti la data
- Provi il ripristino prima in un ambiente di test, se possibile
- Prepari un messaggio temporaneo per i clienti prima di mettere in produzione il ripristino
- Non rimetta in produzione lo stesso backup prima di aver corretto la causa del problema
Cosa guardare nella scelta di uno strumento o servizio di backup
La prima cosa da verificare nella scelta di uno strumento di backup è dove viene davvero conservato il backup; uno strumento che salva solo sullo stesso server non offre protezione reale se quel server si guasta. Il secondo punto è quanta competenza tecnica richiede davvero un ripristino; uno strumento che un imprenditore può ripristinare con un clic dal pannello permette di agire in fretta senza aspettare un team tecnico.
Il terzo punto è la conservazione, fino a dove lo strumento tiene davvero le versioni. Alcuni conservano solo gli ultimi giorni, il che diventa inutile se un problema resta inosservato per settimane prima di essere notato; uno strumento che conserva alcune settimane di versioni offre una protezione reale contro questo tipo di scoperta tardiva.
Un buon piano di backup non si giudica dal fatto che il backup esista, ma dal fatto che funzioni davvero una volta ripristinato; dove viene conservato e fino a dove risale contano quanto lo strumento stesso. In una verifica tecnica con rabbitclip possiamo controllare il suo assetto di backup attuale e colmare insieme le lacune.
Domande frequenti
I backup dovrebbero essere automatici o manuali?
Automatici. Un backup manuale finisce per essere dimenticato. Un calendario regolare impostato dal pannello di hosting o da un plugin toglie l'errore umano dal processo.
Quante copie di backup dovrebbero essere conservate?
Non esiste un numero fisso; almeno una copia attuale dovrebbe essere indipendente dal server in produzione, e qualche versione più vecchia protegge da problemi rimasti inosservati per un po'.
Se il sito viene violato, un backup basta da solo?
Un backup permette di tornare a una versione pulita, ma non chiude la falla usata dall'attacco; la vulnerabilità va trovata e corretta prima del ripristino, altrimenti lo stesso problema si ripete.
Chi dovrebbe scrivere il piano di disaster recovery?
Chi ospita o gestisce il sito, spesso un'agenzia, dovrebbe scriverlo, ma l'imprenditore deve comunque sapere chi chiamare e cosa ha la priorità.
A cosa prestare più attenzione nella scelta di uno strumento di backup?
A dove conserva il backup e a quante versioni tiene; un backup che vive solo sullo stesso server e copre un solo giorno non basta contro problemi scoperti tardi.
