Un piano di backup utile per il sito web spiega che cosa si può recuperare, a quale momento precedente si può tornare e chi eseguirà il ripristino. Prima di accettare «backup inclusi», chiedi un elenco dei sistemi coperti, dei punti di ripristino conservati e una dimostrazione sicura che il sito concordato possa essere ripristinato. Una notifica di backup riuscito, da sola, non risponde a queste domande.
Questa checklist di backup e ripristino del sito web aiuta un'azienda a concordare i requisiti di recupero con il proprio fornitore web o di hosting. La soluzione adatta dipende da ciò che il sito memorizza e da come l'azienda lo usa. Un sito di servizi di cinque pagine, un sito editoriale e un negozio online possono avere esigenze di ripristino molto diverse.
1. Elenca ciò da cui dipende il sito web
Parti dagli elementi necessari per far funzionare il sito, anziché dal nome di un prodotto di backup. Includi contenuti delle pagine, immagini, codice, configurazione ed eventuali database. Poi elenca separatamente i servizi collegati: la destinazione di un modulo, un sistema di prenotazione, un fornitore di pagamenti o un sistema di gestione delle relazioni con i clienti possono conservare informazioni al di fuori dell'account di hosting del sito.
Una copia delle pagine visibili non comprende necessariamente quegli altri dati. Per esempio, WordPress spiega che un tipico backup completo richiede sia i file del sito web sia il database. Scaricare soltanto i file non acquisisce il database. Anche i file e il database devono corrispondere a un punto compatibile nella storia del sito, soprattutto in prossimità degli aggiornamenti.
Per un sito generato da un repository di codice, chiedi che cos'altro serve per ricostruirlo e pubblicarlo. La guida di GitHub ai backup distingue i dati inclusi nei diversi metodi di backup. Una copia del repository è utile, ma non si deve presumere che contenga ogni risorsa caricata, record esterno, impostazione dell'account o requisito di pubblicazione.
Usa una piccola tabella di copertura per rendere visibili questi confini. È una scheda di pianificazione, non un'affermazione che ogni sito abbia bisogno di tutte le righe. Sostituisci gli esempi con i sistemi effettivamente usati dalla tua azienda e registra il responsabile di ciascuno.
| Elemento | Domanda da risolvere | Riscontri da conservare |
|---|---|---|
| Pagine, codice e risorse di design | Si può ricostruire o ripristinare la versione concordata? | Versione, posizione e istruzioni di ripristino |
| Database e contenuti multimediali caricati | Sono entrambi acquisiti in un insieme di ripristino compatibile? | Date dei backup, copertura ed esito del ripristino |
| Configurazione e accesso | Chi può ripristinare le impostazioni e ottenere l'accesso autorizzato? | Responsabile e procedura di accesso sicuro |
| Richieste, prenotazioni o ordini | Quale sistema conserva effettivamente questi record? | Fornitore e modalità di ripristino separati |
| Dominio e servizi collegati | Quali dipendenze devono funzionare prima di poter usare il sito? | Responsabili degli account e checklist delle dipendenze |
2. Concorda la perdita di dati e il tempo di fermo accettabili
Due domande semplici rendono il piano più utile: quante informazioni recenti potrebbe permettersi di perdere l'azienda e per quanto tempo potrebbe restare indisponibile il servizio interessato? Rispondi pensando al processo aziendale, non soltanto alla homepage. Una pagina statica di presentazione e un sistema che accetta ordini pagati possono richiedere risposte diverse.
Queste domande corrispondono all'obiettivo del punto di ripristino, o RPO, e all'obiettivo del tempo di ripristino, o RTO. AWS definisce questi obiettivi di ripristino in termini di intervallo accettabile di perdita di dati e durata massima accettabile dell’interruzione del servizio. Considerali obiettivi di pianificazione concordati. Non dimostrano che un determinato fornitore possa rispettarli in ogni incidente.
Per esempio, un punto di ripristino giornaliero può lasciare scoperto un intervallo contenente le modifiche apportate dopo l'ultimo backup riuscito. La sua esistenza non dice, da sola, quanto rapidamente qualcuno possa individuarlo, ottenere l'accesso, ripristinarlo e verificare il risultato. Chiedi al fornitore di collegare la frequenza proposta e il processo di ripristino agli obiettivi che hai indicato.
Evita di scegliere «nessuna perdita di dati» o «ripristino istantaneo» solo perché queste espressioni sembrano rassicuranti. Spiega quali informazioni non si possono ricreare e quali attività aziendali possono usare temporaneamente un canale alternativo. Poi concorda una soluzione fattibile, il suo costo e gli eventuali limiti. Registra gli orari in cui è disponibile l'assistenza per il ripristino, compresa la gestione di un incidente al di fuori di tali orari.
3. Conserva punti di ripristino utilizzabili abbastanza a lungo
La frequenza dei backup e la conservazione rispondono a domande diverse. La frequenza riguarda quanto spesso viene creato un nuovo punto di ripristino. La conservazione riguarda per quanto tempo restano disponibili quelli precedenti. Un backup frequente che sostituisce ripetutamente l'unica copia può essere poco utile quando una modifica indesiderata viene scoperta diversi giorni dopo.
Chiedi quante versioni vengono conservate, come se ne identificano le date e che cosa succede quando si raggiungono i limiti di archiviazione o cambia l'abbonamento. Considera il tempo che il team potrebbe impiegare per accorgersi di un problema. Se nessuno controlla i contenuti per diverse settimane, un periodo di conservazione molto breve potrebbe terminare prima che venga scoperta un'eliminazione accidentale.
Chiarisci come le copie di ripristino siano separate dall'ambiente di produzione e chi possa modificarle o eliminarle. Una copia coinvolta nella stessa azione errata sull'account o nello stesso incidente di sicurezza potrebbe non offrire l'indipendenza prevista. Discuti controlli di accesso e protezione con il fornitore responsabile, anziché presumere che bastino una seconda cartella o la sincronizzazione automatica.
Mantieni il piano pratico: identifica la posizione delle copie di ripristino e il responsabile dell'account senza inserire password, chiavi segrete o record dei clienti in un brief condiviso. Registra dove vengono mantenute le istruzioni per l'accesso autorizzato. Concorda anche chi riceve le notifiche di errore e che cosa fa quando un backup programmato non viene completato.
4. Distingui rollback, recupero selettivo e ripristino completo
Problemi diversi richiedono metodi di recupero diversi. Il rollback di una pubblicazione riporta il sito pubblicato a una versione precedente. Il recupero selettivo recupera un file, una pagina o un record specifico. Un ripristino completo ricostruisce l'ambiente coperto a partire da un insieme di dati di ripristino. Chiedi quali di questi metodi siano supportati dalla soluzione concordata e che cosa modifichi ciascuno.
Per esempio, Cloudflare Pages documenta il rollback a una precedente pubblicazione in produzione riuscita. È utile per un problema introdotto da una pubblicazione. Non dimostra che anche una piattaforma di prenotazione separata o un database esterno dei clienti torneranno a quel momento. Conferma il comportamento di ogni dipendenza, anziché trattare il «rollback» come un pulsante universale per annullare tutto.
Prima di ripristinare dati precedenti, individua le modifiche apportate dopo quel punto di ripristino. Un ripristino completo del database può sostituire informazioni più recenti e valide insieme alla modifica indesiderata. Stabilisci se quei record successivi possano essere conservati, riconciliati o recuperati separatamente. La persona che autorizza il ripristino dovrebbe comprendere questo compromesso prima dell'inizio di un'operazione distruttiva.
Registra il percorso decisionale con parole semplici: chi valuta il problema, chi approva il punto di ripristino scelto e chi esegue il lavoro. Includi, quando opportuno, un modo per mantenere disponibile lo stato attuale per le indagini. Il piano di ripristino deve spiegare come il team sceglie un metodo, non incoraggiare il titolare dell'azienda a fare esperimenti sul sito in produzione.
5. Dimostra un ripristino in un ambiente sicuro
Chiedi un test di ripristino coordinato prima di fare affidamento sul piano. AWS raccomanda test periodici di ripristino per verificare che i dati dei backup possano essere recuperati e utilizzati. La domanda pratica è se l'insieme di ripristino concordato produca un sito utilizzabile, non se esista un file di archivio.
Usa una destinazione di test isolata, concordata con il responsabile tecnico. Mantieni l'accesso controllato alle informazioni dei clienti ripristinate e impedisci alle copie di prova di inviare notifiche reali, accettare pagamenti o sovrascrivere integrazioni in produzione. Il team responsabile dovrebbe decidere quali dati siano adatti al test e come verranno rimossi in seguito.
Esamina le pagine ripristinate, le immagini, la navigazione e la configurazione necessaria. Verifica un percorso aziendale rappresentativo con modalità di test coordinate. Una pagina visualizzata correttamente non dimostra che il servizio collegato sia configurato correttamente. Quando non è possibile verificare in sicurezza una dipendenza, registra tale limite invece di considerare dimostrato l'intero percorso.
Conserva un breve registro del test: punto di ripristino utilizzato, sistemi coperti, destinazione, orari di inizio e fine, controlli eseguiti e problemi irrisolti. Misura le fasi rilevanti per l'obiettivo di ripristino concordato, compresi accesso e verifica. Ripeti i controlli pertinenti dopo modifiche significative al sito, all'hosting o alla soluzione di ripristino, con una frequenza di revisione concordata in base alle tue circostanze.
6. Esamina una decisione di ripristino realistica
Considera un'ipotetica società di consulenza con un piccolo sito di servizi. Le pagine vengono pubblicate da un repository e le richieste sono conservate in un sistema separato. Martedì pomeriggio, il team scopre che una pubblicazione di lunedì ha rimosso una pagina di servizio. Martedì mattina è arrivata una nuova richiesta.
La prima domanda è se il problema riguardi soltanto le pagine pubblicate o anche il sistema delle richieste. Se una pubblicazione precedente contiene la pagina mancante, il team può valutare un rollback senza presumere di dover ripristinare anche i record separati delle richieste. Controlla quali altre modifiche del sito verrebbero annullate e se recuperare la singola pagina sia un'opzione migliore.
In un'anteprima isolata, il fornitore responsabile dimostra la versione proposta e verifica i link e la configurazione del modulo concordati. Il titolare dell'azienda esamina le modifiche interessate e autorizza il ripristino in produzione attraverso il processo stabilito. Il record più recente del sistema delle richieste viene considerato separatamente perché le sue modalità di archiviazione e ripristino sono distinte.
Questo esempio descrive un metodo decisionale, non un risultato riportato di un cliente o una promessa sui tempi di ripristino. Per un negozio online con ordini memorizzati nel database del sito, la stessa decisione dovrebbe tenere conto degli ordini creati dopo il punto di ripristino proposto. La lezione utile è individuare dove si trovano le informazioni prima di scegliere che cosa ripristinare.
7. Inserisci le responsabilità di ripristino nell'accordo
Concludi con una breve checklist a cui entrambe le parti possano rispondere. Conservala con i materiali di consegna del sito web e riesaminala quando il sito cambia. Deve restare comprensibile per chi dovrebbe segnalare un incidente, anche se quella persona non ha commissionato il progetto originale.
- Sappiamo quali componenti del sito web e quali sistemi esterni sono coperti.
- Abbiamo concordato gli obiettivi di ripristino, la frequenza dei backup e la conservazione.
- Sappiamo chi controlla gli errori e chi può ottenere l'accesso autorizzato per il ripristino.
- Comprendiamo i metodi di ripristino supportati e il rischio per i dati più recenti.
- Abbiamo un registro datato del test di ripristino, con limiti e azioni successive.
- Abbiamo concordato responsabilità, disponibilità ed eventuali costi separati di ripristino.
Aggiungi i requisiti irrisolti al brief del progetto web. Se la pianificazione del ripristino accompagna un sito sostitutivo, usa la checklist per il redesign per la transizione complessiva. Un accordo di ripristino chiaro riduce le supposizioni quando si verifica un incidente; dovrebbe descrivere ciò che è stato concordato e dimostrato.
Il servizio siti web di Digital Studio parte da EUR 2.190 per una realizzazione una tantum fino a cinque pagine con contenuti forniti dal cliente, design responsive, basi SEO, un modulo di acquisizione contatti e lancio sul tuo dominio. Le modalità di backup, i test di ripristino e l'assistenza continuativa per il recupero devono essere discussi e definiti esplicitamente nell'ambito del tuo progetto. Descrivi il tuo sito e i requisiti di ripristino per concordare responsabilità ed eventuali attività aggiuntive prima che inizi la realizzazione.
