Un backup completato senza errori può rivelarsi inutilizzabile proprio quando serve. Il file è stato generato, il sistema ha registrato l’operazione e nella cartella di destinazione compare un archivio con la data corretta. Poi arriva il momento di ripristinare il sito e si scopre che manca il database, che alcune immagini non sono state salvate oppure che la procedura richiede credenziali non più disponibili.
È uno dei problemi più insidiosi nella gestione dei siti web: l’esistenza di una copia di sicurezza non dimostra che il sito possa essere ripristinato. Il controllo decisivo riguarda la possibilità di ricostruire un ambiente funzionante, con contenuti, configurazioni e funzionalità coerenti con il momento in cui è stata effettuata la copia.
La documentazione ufficiale di WordPress distingue espressamente il salvataggio dei file da quello del database. Anche le indicazioni del National Institute of Standards and Technology (NIST) e le buone pratiche di affidabilità dei sistemi informatici richiamano la necessità di verificare periodicamente le procedure di recupero.
Per un sito aziendale, un magazine o un negozio online, organizzare correttamente il backup dei siti WordPress significa quindi affrontare tre questioni: quali dati conservare, come proteggerli da un guasto o da una compromissione e come accertare che siano effettivamente recuperabili.
File e database devono appartenere alla stessa copia
WordPress utilizza normalmente un database MySQL o MariaDB per conservare articoli, pagine, commenti, impostazioni e numerose informazioni prodotte dai plugin. Le immagini, i documenti caricati, i temi e gran parte del codice applicativo si trovano invece nel filesystem del server.
Scaricare la directory del sito tramite FTP non equivale, di conseguenza, a eseguire un backup completo. Allo stesso modo, esportare il database non permette di recuperare automaticamente i file multimediali presenti nella libreria.
La documentazione tecnica di WordPress identifica proprio in questa separazione una delle condizioni da considerare nella preparazione delle copie di sicurezza.
La directory wp-content richiede particolare attenzione perché contiene normalmente i file caricati dagli utenti, i temi e i plugin. Anche il file wp-config.php è rilevante: conserva i parametri necessari al collegamento con il database e altre configurazioni dell’installazione. Trattandosi di un documento che può contenere informazioni riservate, deve essere protetto anche quando viene archiviato nei backup.
Un ulteriore problema riguarda la coerenza temporale. Se il database viene salvato alle 10:00 e la directory dei file alle 11:30, le due copie potrebbero rappresentare stati diversi del sito.
Durante quell’intervallo potrebbero essere stati pubblicati articoli, caricati allegati o modificati prodotti. Nel ripristino si rischierebbe di ottenere riferimenti a immagini assenti oppure file che non corrispondono più alle informazioni registrate nel database.
Database e filesystem dovrebbero quindi costituire un insieme coerente, identificato da una stessa operazione di backup. Nei siti con aggiornamenti frequenti possono essere necessarie procedure capaci di mantenere la consistenza dei dati durante il salvataggio, mediante snapshot coordinati, strumenti specifici o una temporanea sospensione delle operazioni di scrittura.
Anche le informazioni generate da servizi esterni meritano una verifica. Ordini, pagamenti, prenotazioni o dati gestiti da piattaforme collegate potrebbero non essere interamente contenuti nell’installazione WordPress. In questi casi occorre stabilire quali informazioni siano recuperabili dal sito e quali dipendano da sistemi autonomi.
Perché una copia conservata sullo stesso server non è sufficiente
Molti servizi di hosting includono procedure automatiche di backup. Possono essere utili per recuperare rapidamente un file cancellato o annullare una modifica accidentale, ma la loro efficacia dipende dall’architettura del servizio e dalle condizioni contrattuali.
Una copia conservata nello stesso ambiente operativo potrebbe essere coinvolta in un malfunzionamento dello storage, in un errore amministrativo oppure in una compromissione delle credenziali.
La questione diventa particolarmente delicata quando un attaccante riesce ad accedere anche al sistema utilizzato per conservare le copie.
Per questa ragione, la Cybersecurity and Infrastructure Security Agency statunitense richiama il modello 3-2-1, secondo il quale i dati importanti dovrebbero essere presenti in tre copie complessive, conservate utilizzando almeno due tipologie di supporto, con almeno una copia collocata in un luogo esterno.
Applicata al backup dei siti WordPress, questa impostazione può tradursi nella presenza del sito operativo, di una copia gestita dall’infrastruttura di hosting e di un ulteriore archivio conservato presso un servizio indipendente.
Il principio va però interpretato in termini di separazione effettiva del rischio. Due copie collocate in cartelle differenti dello stesso server non offrono la stessa protezione di archivi conservati su infrastrutture indipendenti.
Anche l’utilizzo di servizi cloud distinti richiede attenzione. Se le copie sono accessibili attraverso le medesime credenziali amministrative, una compromissione potrebbe interessarle entrambe.
Un sistema di backup più robusto dovrebbe prevedere autorizzazioni separate, autenticazione multifattore per gli account amministrativi e, quando appropriato, meccanismi di conservazione immutabile.
L’immutabilità impedisce di modificare o cancellare determinate copie durante un periodo prestabilito, nei limiti delle garanzie offerte dal servizio utilizzato. Una copia offline, invece, rimane scollegata dai sistemi ordinariamente accessibili attraverso la rete.
Si tratta di protezioni differenti, che possono essere adottate insieme.
Versionamento: conservare più date per recuperare il momento corretto
La conservazione di un solo backup aggiornato quotidianamente presenta un limite evidente: se un problema viene scoperto dopo diversi giorni, anche la copia più recente potrebbe contenerlo.
Un’infezione informatica, una modifica errata al database o un malfunzionamento introdotto da un aggiornamento possono rimanere inosservati per un certo periodo.
Il versionamento consente di mantenere copie riferite a momenti diversi, aumentando la possibilità di individuare uno stato precedente al problema.
La frequenza dei salvataggi e il tempo di conservazione dovrebbero dipendere dall’attività svolta dal sito.
Un portale istituzionale aggiornato occasionalmente può tollerare intervalli di backup diversi da quelli di un e-commerce che registra continuamente ordini, modifiche ai prodotti e aggiornamenti delle disponibilità.
Una politica possibile, da adattare alle esigenze operative, consiste nel mantenere copie giornaliere per un periodo limitato e versioni settimanali o mensili per un arco temporale più lungo.
Occorre distinguere anche tra backup completi, incrementali e differenziali. I primi comprendono tutti gli elementi selezionati per il salvataggio. I backup incrementali registrano le modifiche rispetto al precedente backup previsto dalla catena, mentre quelli differenziali conservano le variazioni rispetto all’ultimo backup completo.
Queste soluzioni possono ridurre spazio occupato e tempi di trasferimento, ma introducono dipendenze da gestire correttamente durante il recupero.
Se manca un elemento indispensabile di una catena incrementale, il ripristino può risultare compromesso. La presenza di numerosi archivi, pertanto, non coincide necessariamente con la disponibilità di altrettanti punti di recupero indipendenti.
Nel progettare il backup dei siti WordPress conviene verificare quali versioni siano realmente ripristinabili, per quanto tempo rimangano disponibili e se la piattaforma permetta di recuperare una singola data senza dipendere da archivi ormai eliminati.
La semplice sincronizzazione dei file merita una considerazione separata. Un sistema che replica immediatamente modifiche e cancellazioni può trasferire anche un errore o un contenuto compromesso. Senza versionamento o altre protezioni, la sincronizzazione non garantisce le stesse possibilità di recupero offerte da una politica di backup.
Il test di ripristino deve avvenire in un ambiente separato
L’unico modo per verificare concretamente che una copia sia utilizzabile consiste nel tentare un ripristino.
Un controllo sull’esistenza del file, sulla sua dimensione o sull’esito dell’operazione automatica costituisce una verifica preliminare. Non dimostra che WordPress possa tornare operativo.
Le raccomandazioni dell’AWS Well-Architected Framework prevedono il recupero periodico dei dati in un ambiente separato, accompagnato da controlli sulla loro integrità e accessibilità.
Per WordPress, una procedura di prova può essere eseguita su uno spazio di staging, su un server temporaneo oppure su un ambiente locale opportunamente configurato.
L’ambiente deve disporre di versioni compatibili di PHP, del database e delle altre componenti necessarie. Eventuali differenze rispetto al server originale vanno documentate, perché potrebbero produrre errori estranei alla qualità del backup.
Il ripristino comprende il trasferimento dei file, la creazione o configurazione del database, l’importazione dei dati e l’adeguamento dei parametri di collegamento.
Quando cambia il dominio o il percorso di installazione, occorre gestire correttamente anche gli indirizzi memorizzati nel database. WordPress e alcuni plugin utilizzano strutture di dati serializzati: una sostituzione indiscriminata delle stringhe può danneggiarle.
Completata l’operazione, la verifica deve riguardare il comportamento effettivo del sito.
L’apertura della homepage rappresenta soltanto il primo controllo. È necessario accertare che le pagine interne siano disponibili, che le immagini vengano caricate, che i collegamenti permanenti funzionino e che sia possibile accedere all’area amministrativa.
Su un sito editoriale è opportuno verificare la presenza degli articoli pubblicati prima della data del backup, insieme a immagini, categorie e metadati.
Su un e-commerce il test deve comprendere prodotti, varianti, ordini storici, configurazioni di spedizione e funzionamento delle integrazioni, adottando precauzioni per evitare transazioni reali.
Un ripristino tecnicamente completato non è necessariamente un ripristino funzionale. Il database può essere importato senza errori mentre alcune funzioni continuano a non operare correttamente.
I test devono inoltre evitare che l’ambiente di prova invii email ai clienti, attivi notifiche, elabori pagamenti o venga indicizzato dai motori di ricerca. La separazione dall’ambiente pubblico è quindi una misura operativa e di sicurezza.
Come documentare un test senza limitarsi alla conferma del plugin
La registrazione dei risultati permette di distinguere una verifica effettiva da un semplice controllo amministrativo.
Per ogni prova dovrebbero essere identificabili la data del backup utilizzato, il suo luogo di conservazione, la versione dell’ambiente di destinazione e il tempo impiegato per completare il recupero.
È utile annotare anche eventuali errori, componenti non funzionanti e interventi manuali necessari.
Un test eseguito con successo soltanto grazie alla presenza del tecnico che ha configurato originariamente il sito può nascondere una dipendenza organizzativa. Se quella persona non fosse disponibile durante un’emergenza, il recupero potrebbe diventare più complesso.
Le istruzioni dovrebbero quindi essere sufficientemente precise da consentire a un altro amministratore autorizzato di ripetere l’operazione.
Un controllo ulteriore riguarda l’integrità degli archivi. Le verifiche mediante checksum, quando supportate dal sistema, consentono di rilevare eventuali alterazioni dei file tra la generazione e il recupero. Non sostituiscono però l’importazione del database e il collaudo applicativo.
La documentazione del test deve riportare anche i problemi risolti e quelli ancora aperti. Se una procedura richiede passaggi non automatizzati, tempi di trasferimento elevati o credenziali aggiuntive, queste circostanze devono essere note prima di un’interruzione effettiva.
Per le installazioni più articolate, ripetere la prova dopo importanti modifiche infrastrutturali può essere altrettanto utile quanto rispettare una frequenza periodica.
Backup automatici e plugin: quali garanzie verificare
L’automazione riduce il rischio di dimenticare i salvataggi, ma richiede un sistema di monitoraggio.
Un plugin può interrompere l’esecuzione per limiti di memoria, spazio insufficiente, problemi di connessione o restrizioni imposte dall’hosting. Alcune operazioni pianificate dipendono inoltre dai meccanismi di esecuzione disponibili sul server.
Nei siti WordPress le attività programmate possono utilizzare WP-Cron, il cui funzionamento ordinario è legato alle richieste ricevute dal sito. Per le operazioni critiche può essere opportuno valutare una pianificazione indipendente, gestita dall’infrastruttura.
La scelta dello strumento dovrebbe considerare le modalità di esportazione dei dati, il supporto alle copie remote, la gestione delle versioni e soprattutto la procedura prevista per recuperare un sito non più accessibile.
Quest’ultimo aspetto è spesso trascurato.
Se il plugin consente il ripristino esclusivamente dall’area amministrativa di WordPress, bisogna sapere come intervenire quando il pannello non funziona o l’intera installazione è stata cancellata.
È quindi utile verificare se gli archivi siano recuperabili e utilizzabili attraverso strumenti esterni al sito originario, se esista una procedura di ripristino manuale e quali dipendenze software siano necessarie.
Analogamente, quando il backup dei siti WordPress viene affidato al provider di hosting, è opportuno conoscere frequenza, periodo di conservazione, modalità di accesso e tempi previsti per l’assistenza.
Un servizio che permette di ripristinare autonomamente una copia può avere caratteristiche operative differenti da uno che richiede l’apertura di un ticket.
Non esiste una soluzione universalmente preferibile: conta la corrispondenza fra le esigenze del sito e le garanzie effettivamente disponibili.
Quanto tempo può rimanere fermo un sito e quanti dati può perdere
La frequenza dei backup dovrebbe essere stabilita partendo dalle conseguenze di un’interruzione, non soltanto dalla disponibilità di spazio di archiviazione.
Nella pianificazione del recupero vengono utilizzati due parametri distinti: Recovery Point Objective (RPO) e Recovery Time Objective (RTO).
L’RPO indica la massima perdita temporale di dati che l’organizzazione è disposta ad accettare. L’RTO rappresenta invece il tempo massimo stabilito per ripristinare il servizio dopo un’interruzione.
Un esempio ipotetico chiarisce la differenza.
Se un negozio online stabilisce un RPO di un’ora, la propria strategia deve prevedere strumenti capaci di recuperare i dati con una perdita temporale non superiore all’obiettivo fissato. Un unico backup notturno non sarebbe normalmente sufficiente.
Se lo stesso negozio definisce un RTO di quattro ore, le procedure e le risorse disponibili devono consentire il ripristino del servizio entro quel limite nelle condizioni considerate.
I due obiettivi sono indipendenti. Si può recuperare rapidamente una copia vecchia di diversi giorni oppure impiegare molte ore per ripristinare dati recentissimi.
Nella pratica bisogna considerare anche la dimensione degli archivi, la velocità di trasferimento, il tempo necessario a importare il database e la disponibilità di un ambiente sostitutivo.
Un backup conservato su un archivio remoto può essere perfettamente integro, ma richiedere tempi di recupero incompatibili con le esigenze aziendali.
Le misurazioni effettuate durante i test permettono di confrontare le prestazioni reali con gli obiettivi stabiliti, evitando di basare il piano di recupero su tempi ipotetici.
La differenza tra recuperare i dati e garantire la continuità operativa
Il backup costituisce uno degli strumenti necessari per recuperare un sistema informatico. Non coincide, però, con un piano di continuità operativa.
La distinzione è presente anche nelle indicazioni del NIST sulla pianificazione delle emergenze informatiche, che comprendono procedure, responsabilità, infrastrutture alternative e modalità di ripresa delle attività.
Nel caso di un sito WordPress, il recupero dei dati potrebbe non essere sufficiente se il problema interessa il provider, il dominio, il servizio DNS oppure componenti esterni indispensabili al funzionamento.
Un piano operativo deve chiarire chi rileva l’incidente, chi decide l’eventuale sospensione del sito, chi avvia il ripristino e quali interlocutori devono essere coinvolti.
Per un e-commerce assume rilievo anche la gestione degli ordini ricevuti prima dell’interruzione o registrati da servizi esterni durante il disservizio. Ripristinare un database precedente senza verificare le transazioni successive potrebbe produrre incongruenze amministrative.
In caso di attacco informatico, inoltre, non è sempre opportuno riportare immediatamente online una copia apparentemente funzionante.
Occorre prima individuare, per quanto possibile, la causa della compromissione, verificare che il punto di ripristino non contenga già elementi malevoli e correggere le vulnerabilità sfruttate. Altrimenti il sito potrebbe essere compromesso nuovamente.
Il piano di continuità deve considerare anche le modalità di comunicazione con clienti e collaboratori, soprattutto quando il sito costituisce un canale essenziale per vendite, prenotazioni o assistenza.
Queste attività appartengono alla gestione dell’emergenza e richiedono decisioni organizzative che nessun archivio di backup può sostituire.
La responsabilità del controllo non termina con la configurazione
L’impostazione iniziale di un sistema automatico non esaurisce la gestione del backup dei siti WordPress.
Nel tempo possono cambiare le dimensioni del database, la struttura delle directory, le funzionalità del sito e le risorse disponibili sul server. Una procedura adeguata al momento dell’installazione potrebbe non esserlo più dopo l’aggiunta di nuovi plugin o di un catalogo prodotti.
Anche l’archiviazione delle copie richiede una verifica amministrativa. Occorre sapere chi può accedere ai backup, chi può eliminarli, quali criteri ne regolano la conservazione e come vengono protetti i dati personali eventualmente contenuti.
Gli archivi di WordPress possono includere informazioni relative a utenti registrati, clienti e ordini. La loro conservazione deve pertanto essere gestita con misure di sicurezza proporzionate, considerando le responsabilità previste dalla normativa sulla protezione dei dati.
La durata di conservazione va stabilita sulla base delle necessità di recupero, degli obblighi applicabili e della minimizzazione dei dati. Mantenere indiscriminatamente copie per anni non rappresenta automaticamente una scelta più sicura.
Quando la gestione tecnica è affidata a un fornitore esterno, le responsabilità dovrebbero essere definite con precisione: chi esegue i backup, chi controlla gli esiti, chi svolge le prove periodiche e chi dispone delle credenziali necessarie per avviare il recupero.
Un elemento spesso trascurato è l’accessibilità delle copie quando termina il rapporto con il fornitore. La possibilità di esportare gli archivi in un formato utilizzabile e di ricostruire il sito su un’infrastruttura diversa riduce la dipendenza da un singolo operatore.
La documentazione dei test costituisce, infine, un riferimento concreto per valutare l’affidabilità della procedura. La data dell’ultima prova, il punto di recupero utilizzato, le funzionalità verificate e il tempo effettivamente impiegato forniscono informazioni più significative della sola indicazione che il backup automatico risulta attivo.
