Come ripristinare in sicurezza un backup del sito web

Pubblicato il 30 aprile 2026

Il ripristino di un sito web di solito inizia nel peggior momento possibile: dopo un aggiornamento errato di un plugin, un account di amministrazione compromesso, un'implementazione non riuscita o un errore del database che è andato in produzione prima che qualcuno se ne accorgesse. Quando ciò accade, sapere come ripristinare un backup del sito web è più importante che avere un backup in primo luogo. Il vero lavoro consiste nel rimettere online il tuo sito senza portare con sé vecchi problemi, dati mancanti o ulteriori tempi di inattività.

Se sei responsabile di un sito aziendale, di un negozio online, di una dashboard SaaS o di un ambiente client, il ripristino più sicuro è raramente quello più veloce. Dipende da cosa è fallito, da quando è iniziato il problema e se è necessario ripristinare l'intero sito o solo una sua parte.

Prima di ripristinare il backup del sito web, fermati e valuta

La prima decisione riguarda l'ambito. Non tutti gli incidenti richiedono un rollback completo. Se un singolo plugin ha danneggiato la tua homepage ma gli ordini recenti continuano a essere scritti nel database, ripristinare tutto dalla notte precedente potrebbe correggere il layout ma cancellare un giorno intero di transazioni. Non è un buon compromesso.

Inizia identificando cosa è cambiato e quando. Controlla le recenti implementazioni, gli aggiornamenti CMS, le installazioni di plugin, le modifiche dei temi, i processi pianificati (cron jobs), le importazioni di database e gli accessi di amministrazione. Se il tuo pannello di hosting o il nostro stack di monitoraggio mostra picchi di errori, servizi falliti o modifiche ai file, usa quella tempistica per restringere il punto di ripristino pulito.

Vuoi anche confermare che tipo di backup hai. Alcuni backup includono sia file che database in un unico archivio. Altri li memorizzano separatamente. Alcuni provider offrono snapshot a livello di server, mentre i backup a livello di applicazione catturano solo il sito web stesso. Un'istantanea completa del server può essere utile, ma può anche ripristinare email, configurazioni, log e applicazioni non correlate sulla stessa macchina.

Ecco perché gli operatori esperti pongono innanzitutto una semplice domanda: cosa deve essere recuperato esattamente?

Come ripristinare un backup del sito web senza peggiorare le cose

Il percorso più sicuro è preservare lo stato attuale prima di toccare qualsiasi cosa. Anche se il sito è danneggiato, esegui un nuovo backup o uno snapshot dell'ambiente danneggiato. Ciò ti fornisce un fallback se il punto di ripristino è incompleto, corrotto o più vecchio del previsto.

Successivamente, metti il sito in modalità di manutenzione, se possibile. Per siti di e-commerce o di appartenenza, questo aiuta a prevenire nuove scritture durante il processo di ripristino. Se non puoi usare la modalità di manutenzione, almeno blocca le modifiche dell'amministratore e metti in pausa i processi pianificati che potrebbero reintrodurre dati errati.

Quindi verifica l'integrità del tuo backup. Un backup è utile solo se può essere effettivamente aperto e ripristinato. Controlla la dimensione dell'archivio, la data e l'ora, i componenti inclusi e se il backup è stato completato con successo. Se hai più punti di ripristino, confrontali. Il backup più recente non è sempre quello più sicuro, soprattutto se malware o dati corrotti si erano già diffusi prima che fosse creato.

Ripristina file e database nell'ordine corretto

La maggior parte dei siti web si basa su due livelli principali: file e database. I file includono il core del tuo CMS, plugin, temi, media e file di configurazione. Il database memorizza post, utenti, impostazioni, ordini, invii di moduli e dati dell'applicazione. Se questi due livelli non sono sincronizzati, il sito potrebbe tornare parzialmente funzionante, il che può essere più difficile da diagnosticare di un'interruzione completa.

Ripristino dei file del sito web

Se il tuo problema è chiaramente legato ai file, come media cancellati, file del tema danneggiati o un'implementazione di codice fallita, potrebbe essere necessario ripristinare solo la web root o una directory specifica. Usa il tuo pannello di controllo, il gestore di backup, SFTP o l'accesso shell per estrarre il backup nella posizione corretta.

Fai attenzione al comportamento di sovrascrittura. Una sovrascrittura cieca può rimuovere asset caricati di recente o modifiche personalizzate apportate dopo il punto di backup. In alcuni casi, il ripristino di una singola directory come wp-content o una cartella tema è sufficiente. In altri, specialmente dopo un malware, una sostituzione pulita di tutti i file dell'applicazione è l'opzione più sicura.

Controlla permessi e proprietà dopo il ripristino. Un motivo comune per cui i siti ripristinati falliscono non sono i contenuti mancanti, ma permessi dei file errati, proprietà utente errata o un file di configurazione che non corrisponde più all'ambiente del server.

Ripristino del database

Se il fallimento comporta contenuti mancanti, dati di checkout danneggiati, problemi di accesso, impostazioni dei plugin o logica dell'applicazione, il database è spesso parte del problema. Esporta il database danneggiato corrente prima di sostituirlo. Quindi importa il backup selezionato utilizzando phpMyAdmin, Adminer, strumenti da riga di comando o il tuo pannello di hosting.

Questo passaggio merita cautela. Ripristinare un vecchio database su un negozio online o un sistema di prenotazione attivo può cancellare nuovi ordini, messaggi, ticket o record di clienti. Se il sito è rimasto parzialmente funzionante dopo l'incidente, considera un recupero parziale invece di un'importazione completa. Ad esempio, potresti ripristinare solo determinate tabelle, o unire i contenuti manualmente se il tuo team ha la capacità tecnica.

Gli utenti esperti spesso ripristinano il database prima in un ambiente di staging. Ciò ti dà spazio per ispezionare i dati, testare il comportamento dell'applicazione e confrontare i record prima di toccare la produzione.

Utilizza lo staging se il sito è importante per le entrate

Un ripristino diretto in produzione è allettante quando la pressione è alta. Ma se il tuo sito web genera vendite, lead, abbonamenti o supporto clienti, testare prima di solito vale qualche minuto in più.

Un ripristino in staging ti consente di confermare che il backup sia pulito, che il sito si avvii correttamente, che il database si connetta e che le funzioni chiave siano ancora operative. Puoi testare l'accesso, il checkout, i moduli, le integrazioni API, i percorsi delle immagini, il comportamento SSL, le attività pianificate e l'accesso all'amministratore senza esporre i visitatori a un sito semi-ripristinato.

Questo è particolarmente utile dopo incidenti di sicurezza. Se era presente malware, il ripristino di un backup infetto reimposta semplicemente il timer finché il sito non si rompe di nuovo. In staging, puoi ispezionare file sospetti, plugin obsoleti, utenti amministratori iniettati e valori di configurazione modificati prima di promuovere qualsiasi cosa in produzione.

Per agenzie e team che gestiscono più siti web, lo staging crea anche una chiara traccia di controllo. Sai cosa è stato ripristinato, da quando e cosa è stato convalidato prima del lancio.

Non dimenticare DNS, cache ed dipendenze esterne

Il ripristino di un sito web non è sempre solo un ripristino di un sito web. A volte i file e il database sono a posto, ma il sito appare ancora danneggiato perché viene servita una vecchia cache, il DNS punta al server sbagliato o una CDN contiene contenuti non aggiornati.

Dopo il ripristino, cancella la cache dell'applicazione, la cache del server, la cache degli oggetti e la cache della CDN. Se il tuo sito utilizza Redis, Varnish o la cache delle pagine nel pannello di controllo, svuota anche questi livelli. Quindi verifica i record DNS, i certificati SSL e le impostazioni del proxy inverso se l'ambiente è cambiato.

Dovresti anche rivedere le dipendenze esterne. Gateway di pagamento, provider SMTP, chiavi API, server di licenza e integrazioni di storage possono fallire dopo un ripristino se le credenziali sono state ruotate o se la configurazione ripristinata punta a un endpoint obsoleto.

Questo è uno dei motivi per cui il supporto di infrastrutture gestite è importante. Quando il ripristino tocca più del sito web stesso, vuoi qualcuno che guardi l'intero stack, non solo la cartella public_html.

Cosa controllare dopo aver ripristinato il backup del sito web

Una volta completato il ripristino, testa il sito come operatore, non solo come visitatore. Apri la homepage, ma testa anche le parti meno visibili dove i problemi si nascondono spesso.

Controlla l'accesso amministratore, i moduli di contatto, il flusso di checkout, la ricerca, gli account utente, il caricamento dei media, i reindirizzamenti, i processi pianificati, SSL e l'invio di email. Rivedi i log degli errori e i log del web server per avvisi che non sono emersi nel browser. Se il tuo sito ha monitoraggio, conferma che i tempi di risposta, l'utilizzo del disco, lo stato del database e lo stato del servizio siano tornati alla normalità.

Per WordPress e piattaforme CMS simili, verifica le versioni dei plugin e gli aggiornamenti automatici. Per app personalizzate, conferma le variabili d'ambiente, i worker delle code e i processi in background. Se il ripristino ha interessato l'intero server, ispeziona le regole del firewall, il comportamento di avvio dei servizi, lo storage montato e i processi di backup pianificati in modo da non risolvere un'interruzione creandone un'altra.

Se clienti o team interni potrebbero essere stati interessati, comunica chiaramente. Informa loro cosa è stato ripristinato, se potrebbero mancare dati recenti e quali passi vengono intrapresi per prevenire un problema ricorrente.

Il miglior piano di ripristino inizia prima dell'interruzione

Il modo più semplice per ripristinare con calma è costruire la tua strategia di backup intorno al recupero, non solo alla conservazione. Ciò significa avere backup a intervalli utili, mantenere più punti di ripristino, separare file e database quando pratico e testare i ripristini prima che un'emergenza forzi la questione.

Significa anche scegliere un hosting che non ti lasci solo quando qualcosa si rompe alle 2:00 del mattino. Buoni strumenti di backup aiutano, ma il supporto umano è ancora importante quando devi decidere tra un rollback di file, un'importazione parziale del database, un ripristino da snapshot o una ricostruzione pulita. In kodu.cloud, questo livello operativo fa parte del valore perché il tempo di inattività raramente arriva con una documentazione ordinata.

Se ricordi una cosa, che sia questa: ripristina il pezzo pulito più piccolo che risolve il problema, testalo correttamente e conserva lo stato danneggiato finché non sei sicuro che il recupero sia completo.

Andres Saar, Ingegnere dell'Assistenza Clienti