Guida al disaster recovery per i team di hosting

Pubblicato il 26 settembre 2026

Una buona guida al disaster recovery inizia prima che arrivi il ticket relativo all'interruzione del servizio. Il tuo team dovrebbe già sapere quali servizi sono prioritari, dove si trovano i backup integri, chi può autorizzare le modifiche e come verranno aggiornati i clienti. Durante un incidente, l'incertezza fa perdere più tempo della maggior parte dei guasti ai server. Il servizio potrebbe essere non disponibile, ma il processo di ripristino dovrebbe rimanere tranquillo.

Per una piccola azienda, un'agenzia, un operatore SaaS o un negozio online, il disaster recovery non riguarda solo la sopravvivenza a un guasto completo del server. Comprende anche eliminazioni accidentali, deployment non riusciti, ransomware, corruzione del database, certificati scaduti, record DNS danneggiati e un account cloud configurato con un po' troppa creatività. Eventi diversi richiedono risposte diverse, ma la preparazione è in gran parte la stessa.

Definisci cosa significa il ripristino per la tua azienda

Inizia da due numeri: Recovery Time Objective (RTO) e Recovery Point Objective (RPO). Non sono documenti burocratici fini a se stessi. Stabiliscono i limiti di un'interruzione accettabile e di una perdita di dati accettabile.

L'RTO è il tempo massimo durante il quale un servizio può non essere disponibile. Se il tuo checkout deve tornare operativo entro un'ora, il suo RTO è di un'ora. L'RPO è la quantità massima di dati che puoi perdere. Un RPO di 15 minuti significa che i backup, la replica o i log delle transazioni devono consentire il ripristino a un punto non precedente di 15 minuti rispetto all'incidente.

Non assegnare lo stesso obiettivo a ogni carico di lavoro. Un sito web vetrina può spesso tollerare un RTO più lungo rispetto a un sistema per gli ordini. Un server di sviluppo può aspettare mentre vengono ripristinati la posta elettronica di produzione, i database dei clienti e le integrazioni di pagamento. Inserisci ogni servizio in un livello di priorità e documentane il responsabile, le dipendenze e l'obiettivo di ripristino.

Mappa le dipendenze prima che si guastino

Un'applicazione web raramente risiede su un solo server. Potrebbe dipendere da DNS, un certificato SSL, un bilanciatore del carico, uno storage a oggetti, un database, un provider di posta, un'API e un worker in background. Ripristinare prima il server web non è utile se manca il suo database o se il DNS continua a indirizzare i visitatori a un indirizzo non disponibile.

Crea una semplice mappa delle dipendenze per ogni servizio critico. Registra i nomi dei server, gli indirizzi IP, i sistemi operativi, le versioni delle applicazioni, le posizioni dei database, l'archiviazione delle credenziali, le regole del firewall, i processi pianificati, le zone DNS e i servizi di terze parti. Conserva queste informazioni in un luogo accessibile al di fuori dell'infrastruttura interessata. Un documento di ripristino conservato solo sul server guasto è una forma molto silenziosa di ottimismo.

Crea backup che puoi davvero ripristinare

Un backup diventa un'opzione di ripristino solo dopo essere stato ripristinato e verificato. I log dei backup completati correttamente mostrano che un processo è terminato. Non dimostrano che i dati copiati siano leggibili, completi, aggiornati o utilizzabili con l'applicazione.

Usa il principio 3-2-1 come base pratica: conserva almeno tre copie dei dati importanti, su due diversi tipi di storage, con una copia conservata fuori sede o in un account separato. Per molti ambienti di hosting, ciò significa snapshot locali per rollback rapidi, storage di backup pianificati al di fuori del server di produzione e un'ulteriore copia protetta in un'altra posizione.

Esegui il backup di qualcosa in più dei file del sito web. Includi database, configurazioni delle macchine virtuali, variabili d'ambiente dell'applicazione, file di infrastructure-as-code, esportazioni DNS, dettagli dei certificati e documentazione del deployment. Se la tua azienda si affida a una piattaforma gestita, verifica cosa protegge e cosa rimane sotto la tua responsabilità. “Pensavamo fosse incluso” non è una strategia di ripristino consigliata.

Adatta la frequenza dei backup alle variazioni dei dati

Un sito web aziendale statico potrebbe richiedere un backup giornaliero. Un database ecommerce molto utilizzato potrebbe richiedere backup ogni ora, la conservazione dei binlog o la replica per rispettare il suo RPO. La scelta giusta dipende dalla velocità con cui cambiano i tuoi dati e dalla quantità di attività persa che può essere riconciliata manualmente.

Anche la conservazione è importante. Conservare solo il backup più recente è rischioso quando la corruzione o il malware sono presenti da giorni. Mantieni più punti di ripristino, così puoi tornare indietro oltre il primo sintomo visibile. Crittografa i backup, limita l'accesso e, ove possibile, usa credenziali separate da quelle della produzione. Un attaccante con accesso completo alla produzione non dovrebbe ottenere automaticamente le chiavi di ogni copia di backup.

Crea un runbook chiaro per gli incidenti

Durante un'interruzione, le persone hanno bisogno di decisioni già prese. Il tuo runbook dovrebbe essere abbastanza breve da poter essere utilizzato sotto pressione e abbastanza dettagliato da poter essere seguito da un'altra persona qualificata. Organizzalo per scenario invece di scrivere un unico documento enorme.

Ad esempio, scrivi procedure separate per un VPS guasto, un database eliminato, un sito web compromesso, un deployment non riuscito e un'interruzione dell'infrastruttura regionale. Ogni procedura dovrebbe indicare come rilevare il problema, come fermare ulteriori danni, dove si trova la fonte di ripristino, la sequenza di ripristino, i controlli di convalida, i contatti per l'escalation e le fasi di comunicazione ai clienti.

In caso di sospetta compromissione, conserva le prove prima della ricostruzione, ove possibile. Isola il server interessato, ruota le credenziali, esamina i log di accesso e identifica il probabile punto di ingresso. Ripristinare un backup integro senza correggere un plugin vulnerabile, un servizio esposto o una password divulgata può riportarti allo stesso incidente prima di pranzo.

Assegna i ruoli, anche in un team piccolo

I team piccoli non hanno bisogno di un comitato formale per le emergenze, ma hanno bisogno di responsabilità precise. Una persona guida il ripristino tecnico, una coordina gli aggiornamenti ai clienti o interni e una approva le decisioni ad alto impatto, se necessario. La stessa persona può ricoprire più di un ruolo, ma le responsabilità devono essere esplicite.

Prepara in anticipo gli aggiornamenti sullo stato. Indica cosa è interessato, cosa si sta verificando, quale soluzione alternativa è disponibile, se presente, e quando verrà fornito il prossimo aggiornamento. Evita di fare supposizioni sui tempi di ripristino. In genere, i clienti gestiscono un incidente difficile meglio del silenzio o di stime ottimistiche che poi svaniscono.

Scegli metodi di ripristino adatti al guasto

Gli snapshot sono utili per un rollback rapido dopo una modifica errata, ma non costituiscono una politica di backup completa. Se gli snapshot rimangono sullo stesso host o sistema di storage compromesso, potrebbero scomparire insieme al carico di lavoro principale. Usali per la velocità, poi mantieni backup indipendenti per la resilienza.

Ripristinare su un'infrastruttura sostitutiva è spesso più sicuro che riparare sul posto un server danneggiato. È possibile predisporre, aggiornare e verificare un VPS nuovo o un server dedicato prima di trasferirvi il traffico. Questo approccio conserva anche il sistema originale per le indagini. Potrebbe richiedere più tempo di un rollback da snapshot, quindi comporta un compromesso tra velocità, affidabilità e natura dell'incidente.

Per i servizi ad alta disponibilità, la replica e il failover possono ridurre i tempi di inattività, ma aumentano la complessità operativa. La replica può copiare i dati errati con la stessa efficienza dei dati corretti. Usa il monitoraggio, repliche ritardate ove appropriato e procedure di failover testate, invece di presumere che la sola ridondanza abbia risolto il ripristino.

Testa il piano secondo una pianificazione

Un piano di ripristino che non è stato testato è un'ipotesi con un documento allegato. Pianifica i test di ripristino almeno ogni trimestre per i sistemi critici e dopo modifiche architetturali importanti. Ripristina un backup in un ambiente isolato, verifica che l'applicazione si avvii, controlla l'integrità del database, testa i percorsi di accesso e delle transazioni e confronta i dati recuperati con il punto di ripristino previsto.

Registra quanto tempo richiede ogni passaggio. Se il ripristino di un database richiede quattro ore ma il suo RTO è di un'ora, il piano non sta fallendo sulla carta. Sta fallendo nell'unico posto che conta. Potresti aver bisogno di un metodo di backup più rapido, unità di ripristino più piccole, un'infrastruttura standby o un obiettivo aziendale rivisto.

Anche il monitoraggio dovrebbe supportare il ripristino. Gli avvisi relativi alla capacità di storage, ai backup non riusciti, alla scadenza dei certificati, a comportamenti insoliti della CPU, al ritardo della replica del database e ai processi pianificati non riusciti possono trasformare un disastro in una correzione ordinaria. Con il monitoraggio gestito, come FASTCARE, l'obiettivo non è semplicemente ricevere un avviso. È fare in modo che un tecnico inizi a controllare i segnali corretti mentre il problema è ancora circoscritto.

Ripristina, convalida e poi chiudi l'incidente

Una volta ripristinato il servizio, non dichiarare subito la vittoria. Convalida la risoluzione DNS, il comportamento SSL, l'accesso tramite firewall, lo stato dell'applicazione, le attività pianificate, la connettività del database, la consegna delle email e i percorsi principali dei clienti. Per un negozio online, testa la navigazione, l'attività del carrello, il checkout, le notifiche degli ordini e i callback dei pagamenti. Per una piattaforma SaaS, testa l'autenticazione, le code in background, le risposte dell'API e l'accesso ai dati dei tenant.

Poi esamina l'incidente mentre i dettagli sono ancora freschi. Che cosa lo ha rilevato? Che cosa ha ritardato il ripristino? Quale passaggio del runbook non era chiaro? I backup hanno rispettato l'RPO richiesto? Trasforma queste risposte in modifiche specifiche con un responsabile e una scadenza. La migliore revisione post-incidente è pratica, non teatrale.

i clienti di kodu.cloud possono combinare infrastruttura gestita, servizi di backup, monitoraggio e supporto umano per ridurre il numero di attività di ripristino che ricadono su una sola persona impegnata alle 2 di notte. Questo non elimina la necessità di un piano, ma fornisce al piano mani esperte quando le condizioni sono meno favorevoli.

L'obiettivo non è promettere che nulla si guasterà mai. Server, software e persone prendono occasionalmente decisioni sorprendenti. L'obiettivo è rendere il ripristino abbastanza prevedibile affinché il tuo team sappia qual è la prossima azione sicura, i tuoi clienti ricevano aggiornamenti chiari e il servizio torni a essere tranquillo.

Andres Saar Ingegnere dell'assistenza clienti