Pubblicato il
Un e-commerce che riceve ordini fino alle 23:59 non può accettare che un errore di aggiornamento lasci il catalogo irraggiungibile fino al giorno dopo. Un esempio disaster recovery sito serve proprio a trasformare un incidente tecnico in una procedura controllata: capire cosa è successo, ripristinare il servizio e verificare che dati, pagamenti e funzionalità siano tornati coerenti.
Il backup è una parte essenziale della protezione, ma non coincide con il disaster recovery. Una copia dei file senza un piano di ripristino, senza priorità e senza test può rivelarsi insufficiente nel momento più delicato. Per un sito aziendale, un portale o un negozio online, la domanda utile non è solo “abbiamo un backup?”, ma “quanto velocemente possiamo tornare operativi e con quali dati?”.
Un esempio di disaster recovery per sito e-commerce
Immaginiamo un negozio online basato su WordPress e WooCommerce, ospitato su un ambiente professionale. Il sito contiene migliaia di prodotti, dati degli utenti, ordini, fatture e integrazioni con corrieri e sistemi di pagamento. Durante l'installazione di un plugin non verificato, alcune tabelle del database vengono danneggiate e il sito mostra errori critici sia nel frontend sia nel pannello di amministrazione.
In questo scenario il titolare non deve intervenire alla cieca modificando file o reinstallando il CMS. Il piano prevede che venga identificata l'ultima copia affidabile, eseguita poco prima dell'aggiornamento problematico. Si ripristinano prima database e file applicativi in un'area separata o in un ambiente di staging, così da controllare che il catalogo, le credenziali amministrative e il processo d'ordine funzionino correttamente.
Se il controllo è positivo, il ripristino viene applicato all'ambiente di produzione. Gli ordini ricevuti tra l'ora del backup e il momento dell'incidente vanno verificati e, se necessario, recuperati da email di conferma, gateway di pagamento o gestionali collegati. Infine, si analizza la causa: plugin vulnerabile, aggiornamento incompatibile, permessi errati o configurazione del server. La correzione della causa evita di ripetere lo stesso fermo alla prima manutenzione successiva.
Questo è un punto spesso sottovalutato: ripristinare un sito non significa solo far sparire una pagina di errore. Significa riportare online un servizio mantenendo l'integrità dei dati e riducendo l'impatto su clienti, vendite e reputazione.
RPO e RTO: i due numeri che definiscono il piano
Un piano di disaster recovery concreto parte da due obiettivi misurabili. L'RPO, Recovery Point Objective, indica quanta perdita di dati è accettabile. L'RTO, Recovery Time Objective, definisce invece il tempo massimo di indisponibilità tollerabile.
Per un sito vetrina aggiornato una o due volte al mese, un backup giornaliero può essere adeguato. Se il sito subisce un problema alle 16 e l'ultima copia risale alla notte precedente, la perdita potenziale riguarda le modifiche della giornata. Per molte realtà questo compromesso è sostenibile, a fronte di costi e gestione contenuti.
Per un e-commerce con ordini continui, un portale di prenotazioni o una piattaforma e-learning, la situazione cambia. Un RPO di 24 ore può voler dire perdere transazioni, iscrizioni o contenuti caricati dagli utenti. In questi casi servono copie più frequenti del database, procedure per riconciliare i dati e un'infrastruttura capace di supportare un ripristino rapido.
Anche l'RTO dipende dal progetto. Un professionista può gestire qualche ora di fermo per un sito istituzionale. Per un'attività che genera vendite ogni giorno, quattro ore di indisponibilità possono costare più di un servizio infrastrutturale adeguato. Definire questi valori prima dell'incidente consente di scegliere hosting, backup e risorse server in modo proporzionato, senza acquistare capacità inutili o restare scoperti.
Cosa deve contenere un piano efficace
Un piano utile deve essere breve abbastanza da poter essere usato sotto pressione, ma completo nei punti decisivi. Non basta indicare “ripristinare il backup”: occorre specificare quale copia usare, chi può autorizzare l'operazione e come verificare il risultato.
La prima parte è l'inventario. Vanno identificati dominio, DNS, hosting o cloud server, database, caselle email coinvolte, certificati SSL, CMS, plugin, temi, API e servizi esterni. Se un sito utilizza un CDN, un sistema di pagamento o un gestionale, il ripristino potrebbe dipendere anche da queste integrazioni. Un elenco aggiornato evita che un dettaglio tecnico blocchi il ritorno online.
La seconda parte definisce le responsabilità. L'agenzia può occuparsi del codice, il proprietario del sito può validare contenuti e ordini, mentre il provider interviene sull'infrastruttura secondo il servizio attivato. Stabilire prima i contatti e i livelli di accesso riduce i tempi morti, soprattutto quando l'incidente avviene fuori orario.
La terza parte è la sequenza operativa. In genere si isola il problema, si preservano log e copie recenti per l'analisi, si verifica l'integrità del backup e poi si procede al ripristino. Al termine si controllano homepage, aree riservate, moduli, email transazionali, checkout, certificato SSL e prestazioni. Se il sito ha utenti attivi, è utile preparare anche un messaggio essenziale: l'obiettivo è informare senza fornire dettagli tecnici confusi o promettere tempi non verificati.
Backup gestito e disaster recovery non sono la stessa cosa
Un backup gestito riduce il rischio di non avere copie disponibili o di dimenticare attività ricorrenti. Soluzioni come R1Soft Backup permettono di impostare una protezione strutturata per dati e ambienti server, con punti di ripristino utili in caso di cancellazioni accidentali, aggiornamenti non riusciti o corruzione.
Il disaster recovery aggiunge però una decisione organizzativa: quale servizio ha priorità, in quanto tempo deve tornare online e quale procedura viene seguita se il server, il database o l'applicazione non sono disponibili. Un backup eccellente può richiedere comunque tempo se nessuno sa dove ripristinarlo, se le risorse sono insufficienti o se le dipendenze applicative non sono documentate.
Per progetti piccoli, un hosting con backup regolari e una procedura scritta può essere una scelta equilibrata. Quando traffico, database e operatività aumentano, un cloud server o un server dedicato gestito offrono più controllo su risorse, configurazioni e strategia di continuità. Non esiste un'architettura identica per tutti: conta il valore reale del sito durante un'interruzione.
Testare il ripristino prima dell'emergenza
Il test è la fase che separa un piano teorico da un piano affidabile. Una copia può essere presente ma incompleta, non leggibile o incompatibile con l'attuale versione del CMS. Inoltre, un backup dei file senza il database non riporta in vita un e-commerce, mentre un database isolato non ricostruisce tema, plugin e media.
Programmare una prova periodica consente di misurare tempi e criticità. Il test può avvenire su un ambiente separato: si ripristina una copia, si controllano accesso al backend, pagine principali, form, ricerca, funzioni di acquisto e integrazioni. Per siti dinamici è opportuno verificare anche cron job, code email e processi automatici.
Dopo ogni prova, il piano va aggiornato con il tempo effettivo impiegato e le attività emerse. Se il ripristino richiede tre ore anziché l'ora prevista, l'RTO dichiarato non è realistico. Se un'integrazione necessita di chiavi API o configurazioni manuali, queste informazioni devono essere documentate e custodite con procedure di accesso sicure.
Errori che allungano il fermo del sito
Il primo errore è conservare i backup sullo stesso spazio del sito. Un guasto grave, una compromissione o una cancellazione può coinvolgere sia la produzione sia le copie. La seconda criticità è affidarsi solo a backup manuali: funzionano finché qualcuno ricorda di eseguirli e di verificarli, ma non sono una garanzia per servizi aggiornati di frequente.
Un altro problema comune è mantenere credenziali, licenze e documentazione in un unico account non accessibile durante l'incidente. Anche la manutenzione rimandata ha un costo: CMS, plugin e componenti obsoleti ampliano la superficie di rischio. Aggiornare con metodo, creare un punto di ripristino prima delle modifiche e provare le novità in staging è spesso più economico che gestire un'emergenza in produzione.
Per chi gestisce più siti clienti, conviene distinguere chiaramente piani, frequenze di backup e responsabilità. Un blog personale e un e-commerce con fatturato giornaliero non meritano la stessa soglia di intervento. La trasparenza su questi limiti evita aspettative irrealistiche quando ogni minuto conta.
Un sito ben protetto non è quello che promette di non fermarsi mai, ma quello che sa reagire con dati verificati, procedure chiare e infrastruttura adeguata. Preparare oggi un ripristino testato permette di affrontare domani un errore, un attacco o un guasto con molte meno decisioni improvvisate.