Un sito web funziona ogni giorno – finché improvvisamente smette di farlo. Un aggiornamento difettoso, un database corrotto, un plugin di WordPress compromesso, un errore umano o un guasto tecnico possono bastare per paralizzare parzialmente o totalmente un sito web.
In questo momento non conta più se da qualche parte esiste un backup. Quello che conta è, se il sito web possa effettivamente essere ripristinato da ciò in tempi ragionevoli.
Proprio qui risiede la differenza tra un semplice salvataggio di dati e una strategia ponderata di backup e disaster recovery.
Cosa significa disaster recovery per un sito web?
Il Disaster Recovery indica le misure con cui sistemi e dati vengono riportati a uno stato operativo dopo un guasto grave.
Su un sito web, un tale incidente può verificarsi, ad esempio, a causa di:
- Guasti hardware o di memoria
- aggiornamenti difettosi di WordPress o di plugin
- database danneggiati
- Malware o siti Web compromessi
- file eliminate accidentalmente
- Errate configurazioni
- Problemi con il provider di hosting
Un backup è una componente importante, ma non ancora una strategia completa di disaster recovery.
Il backup e il disaster recovery non sono la stessa cosa
Un backup risponde innanzitutto solo alla domanda: Esiste una copia dei miei dati?
Il Disaster Recovery va oltre: Come faccio a trasformare questa copia di nuovo in un sistema funzionante?
Nel caso di un sito WordPress, ad esempio, non basta eseguire il backup solo delle immagini caricate. Per un ripristino completo sono necessari, tra le altre cose, i file di WordPress e il database.
A seconda dell'ambiente, si aggiungono configurazioni, impostazioni DNS, certificati SSL o altri componenti.
Ecco perché la domanda più importante non è: „Abbiamo i backup?“
Bensì: „Possiamo ripristinare in modo affidabile il nostro sito web da questi backup?“
Perché un backup sullo stesso sistema può essere problematico
Un backup offre protezione solo se è sufficientemente indipendente dal sistema originale.
Se l'unico backup si trova, ad esempio, sullo stesso server del sito web di produzione, un guasto grave può interessare entrambi contemporaneamente.
Lo stesso vale per i sistemi compromessi: se un attaccante ottiene un accesso esteso, in circostanze sfavorevoli potrebbero essere interessati anche i backup archiviati localmente.
Una strategia di backup ben concepita tiene quindi conto della separazione tra sistema di produzione e backup.
La regola del 3-2-1 come orientamento
Una nota regola fondamentale per i backup dei dati è la cosiddetta Regola di backup 3-2-1.
Semplificata, significa:
- 3 copie dei dati importanti
- su 2 diversi supporti di memorizzazione o sistemi
- di cui almeno 1 copia separata dalla posizione principale
Non ogni piccolo sito web necessita necessariamente di una complessa infrastruttura di backup aziendale.
Il principio di base rimane tuttavia sensato: Il backup non dovrebbe poter essere soggetto allo stesso errore dell'originale.
Con quale frequenza dovrebbe essere eseguito il backup di un sito web?
La giusta frequenza di backup dipende da quanto spesso cambiano i dati di un sito web.
Per un sito di club o informativo in gran parte statico, può essere opportuna una strategia diversa rispetto a un negozio WooCommerce molto frequentato.
Un negozio online, ad esempio, modifica continuamente:
- Ordini
- Conti clienti
- Scorte di magazzino
- Informazioni di pagamento e dati sullo stato
Più dati vengono generati tra due backup, maggiore può essere la perdita in caso di ripristino.
RPO e RTO: Due concetti che descrivono il rischio effettivo
Nei concetti di backup professionali vengono spesso utilizzate due metriche: RPO e RTO.
RPO – Recovery Point Objective
In parole semplici, l'RPO descrive quanta perdita di dati sarebbe accettabile nello scenario peggiore.
Se, ad esempio, viene eseguito un backup una volta al giorno, teoricamente le modifiche apportate dall'ultimo backup potrebbero andare perse.
Per un sito web semplice questo può essere accettabile. Per un negozio online attivo, probabilmente no.
RTO – Obiettivo di Tempo di Ripristino
L'RTO descrive per quanto tempo al massimo un sistema può rimanere inattivo prima di dover essere ripristinato.
Anche qui i requisiti differiscono notevolmente.
Un sito web privato potrebbe rimanere offline per qualche ora o più. Per un negozio online di importanza vitale per il business, anche un breve periodo di inattività può costare fatturato.
Perché più versioni di backup sono importanti
Un singolo backup recente non è sempre sufficiente.
Il problema: Un errore o una compromissione può già sussistere inosservato da diversi giorni.
Se viene sovrascritta una sola copia di backup al giorno, prima o anche il backup potrebbe contenere lo stato errato o compromesso.
I backup con controllo di versione, d'altra parte, consentono di tornare a uno stato precedente.
Ecco perché diversi punti di ripristino sono una componente importante di una buona strategia di backup.
Un backup è valido solo se il ripristino funziona
Uno degli errori più comuni consiste nel far creare i backup automaticamente, ma nel non verificare mai se possano effettivamente essere utilizzati.
Un messaggio di backup riuscito non significa ancora automaticamente che da esso si possa ripristinare un intero sito web senza errori.
Pertanto, i sistemi di backup e i processi di ripristino dovrebbero essere verificati regolarmente.
Ulteriori basi in merito sono disponibili nella nostra guida: Strategie di backup: ciò che conta davvero .
WordPress pone requisiti particolari per i backup
WordPress non consiste solo in file. Gran parte del sito Web si trova nel database.
Lì si trovano, ad esempio:
- Articoli e pagine
- Account utente
- Impostazioni di WordPress
- Configurazioni dei plugin
- Dati WooCommerce
Un backup completo di WordPress deve quindi tenere conto dei file e del database.
Proprio prima di aggiornamenti importanti o modifiche, un punto di ripristino aggiornato è particolarmente importante.
Cosa succede a un sito WordPress hackerato?
In caso di incidente di sicurezza, il ripristino è più complesso rispetto a quello successivo all'eliminazione accidentale di un file.
Ripristinare semplicemente l'ultimo backup può essere problematico se questo contiene già codice maleffico o se la vulnerabilità originale persiste.
Perciò bisogna prima chiarire:
- Come è stato compromesso il sito web?
- Da quanto tempo è in corso l'attacco?
- Quale punto di ripristino è ancora pulito?
- È stata risolta la vulnerabilità originale?
Spieghiamo di più al riguardo nell'articolo: WordPress è stato hackerato: e adesso? .
Backup dell'hosting e backup aggiuntivo del sito web
Un backup dell'hosting e un ulteriore backup separato del sito web non svolgono necessariamente la stessa funzione.
Il backup dell'hosting serve tipicamente al ripristino all'interno dell'ambiente di hosting esistente.
Una soluzione di backup aggiuntivo può invece creare un ulteriore livello di salvataggio indipendente.
Se tale protezione aggiuntiva sia necessaria dipende dal valore e dalla criticità del sito web.
CodeGuard come livello di backup aggiuntivo
Per i siti Web per i quali si desidera un backup aggiuntivo e separato dal vero e proprio web hosting, può essere utile una soluzione di backup esterna.
CURIAWEB offre a questo scopo, tra le altre cose, CodeGuard un.
CodeGuard può eseguire regolarmente il backup di siti Web indipendentemente dall'hosting effettivo e monitorare le modifiche. Ciò crea un livello di backup aggiuntivo che non dipende esclusivamente dall'infrastruttura di backup dell'hosting web.
Questo è interessante, ad esempio, se un sito web è ospitato presso un altro fornitore o se si desidera un backup aggiuntivo per un sito web particolarmente importante.
Ulteriori informazioni: Backup del sito web CodeGuard .
Cosa c'entra la protezione dei dati con i backup?
I backup possono contenere dati personali. Per questo motivo, devono essere presi in considerazione in un concetto di protezione dei dati esattamente come i sistemi di produzione.
Tra gli altri, sono rilevanti:
- Controllo degli accessi
- Periodo di conservazione
- Posizione di salvataggio
- Protezione da accesso non autorizzato
- Processi di eliminazione e ripristino
Un backup non costituisce quindi automaticamente una misura completa di protezione dei dati. Esso rappresenta una componente di un concetto di sicurezza tecnico e organizzativo più ampio.
Cosa succede se l'intero provider di hosting subisce un'interruzione?
Anche questa domanda fa parte di un'analisi realistica del rischio.
Chi dipende completamente da un unico fornitore, da un solo accesso e da un'unica infrastruttura di backup dovrebbe almeno sapere come poter accedere ai propri dati in caso di emergenza.
Per i siti Web critici per il business, può quindi essere utile un ulteriore backup indipendente dall'hosting.
In caso di estrema necessità, questo consente di ripristinare un sito web anche in un altro ambiente di hosting.
Un cambio di hosting può essere parte della strategia di emergenza
Se si manifestano problemi duraturi di prestazioni, stabilità, sicurezza o supporto, non si dovrebbe aspettare un guasto totale.
Un cambio di hosting controllato è molto più semplice di una migrazione sotto pressione durante un'emergenza.
CURIAWEB si fa carico gratuitamente della migrazione dei siti web esistenti per i nuovi clienti in caso di passaggio.
Per saperne di più: Trasferimento hosting con servizio di migrazione gratuito .
Qual è la strategia di backup giusta?
Non esiste una strategia di backup che debba essere identica per ogni sito web.
Una soluzione sensata si orienta al rischio effettivo.
A tal proposito, si dovrebbe rispondere in particolare alle seguenti domande:
- Quanto è importante il sito web per me o per la mia organizzazione?
- Con quale frequenza vengono aggiornati i dati?
- Quanta perdita di dati sarebbe accettabile?
- Quanto tempo potrebbe rimanere offline il sito web?
- Quanti punti di ripristino precedenti mi servono?
- Dove si trovano i backup?
- Il sito web può essere ripristinato anche su un'altra infrastruttura?
- È già stato testato il ripristino?
Un piccolo sito web privato, il sito di un'associazione, un sito aziendale e un negozio WooCommerce possono quindi avere esigenze completamente diverse.
Conclusione: non conta il backup, ma la recuperabilità
I backup sono tra le basi più importanti per la gestione affidabile di un sito web.
La domanda decisiva non è tuttavia se esista una salvaguardia da qualche parte.
Ciò che è determinante è, se vengano salvati i dati corretti, quanto siano aggiornati i backup e se da essi si possa ripristinare un sito web funzionante in caso di emergenza.
Una buona strategia di disaster recovery tiene quindi conto non solo dei backup, ma anche dei tempi di ripristino, del versionamento, dell'indipendenza dal sistema di produzione e di test regolari.
Più un sito web è importante, meno il suo ripristino dovrebbe essere affidato al caso.
