Come automatizzare in sicurezza i backup di WordPress

Pubblicato il 7 novembre 2026

Un backup di WordPress è utile solo se contiene i dati giusti e può essere ripristinato prima che l’interruzione del servizio abbia ripercussioni sull’attività. Per automatizzare in sicurezza i backup di WordPress, pianifica l’esportazione sia dei file sia del database, invia le copie al di fuori del server di produzione e verifica che il ripristino funzioni davvero. Un processo di backup che segnala il successo ma salva un archivio vuoto non protegge nulla. È solo un problema molto cortese in attesa del venerdì sera.

Cosa include un backup completo di WordPress

WordPress non è una cosa sola. I contenuti del sito, la configurazione, i plugin, i temi, i file multimediali caricati e i dati degli utenti sono distribuiti tra il file system e il database. Per un ripristino completo servono entrambi.

Il database contiene articoli, pagine, ordini WooCommerce, account cliente, voci dei moduli, impostazioni e altri contenuti soggetti a modifiche. Il file system contiene i file core di WordPress, i plugin, i temi, i caricamenti e file come `wp-config.php`. Se ripristini solo i file, il sito potrebbe caricarsi con contenuti obsoleti o mancanti. Se ripristini solo il database, potrebbe fare riferimento a file inesistenti.

Per molti siti aziendali, il minimo pratico consiste in un backup giornaliero del database e un backup giornaliero dell’intero sito. I negozi di e-commerce, le piattaforme di iscrizione, i sistemi di prenotazione e gli ambienti SaaS con pagine di destinazione molto frequentate potrebbero aver bisogno di backup del database più frequenti, perché ogni ora possono arrivare nuovi ordini e dati dei clienti. La pianificazione dovrebbe riflettere la quantità di dati che puoi permetterti realisticamente di perdere, non ciò che sembra più comodo.

Scegli il livello giusto per l’automazione

Esistono tre metodi comuni per automatizzare i backup di WordPress: un plugin di backup per WordPress, il pannello di controllo o il servizio gestito del provider di hosting e processi a livello di server. Nessuno è il migliore in assoluto. La scelta giusta dipende da chi gestisce il server, dalle dimensioni del sito e dalla rapidità con cui devi ripristinarlo.

Backup basati su plugin

Per un sito piccolo, un plugin è spesso l’opzione più semplice. Può creare archivi, pianificare processi e inviare backup a uno spazio di archiviazione remoto senza accesso alla shell. Questo offre ai proprietari dei siti visibilità diretta ed è utile quando il piano di hosting non include un servizio di backup.

Il compromesso è il carico sul server. Comprimere una libreria multimediale di grandi dimensioni mentre il sito è visitato dagli utenti può consumare CPU, memoria, I/O del disco e processi PHP. In un ambiente condiviso molto frequentato o su un VPS di piccole dimensioni, i processi di backup potrebbero interrompersi per timeout o rallentare le pagine di pagamento. Se possibile, configura il processo nelle ore di minor traffico e controlla le prime esecuzioni invece di dare per scontato che la pianificazione sia corretta.

Backup del provider di hosting o gestiti

I backup a livello di hosting vengono eseguiti al di fuori di WordPress, in genere con maggiore sicurezza in caso di malfunzionamento di un plugin, incidente malware o aggiornamento di WordPress andato storto. Un sistema di backup gestito può acquisire database e file senza dipendere dal corretto funzionamento dell’applicazione del sito.

Questo approccio riduce il numero di elementi da gestire all’interno di WordPress e in genere semplifica il ripristino a livello di infrastruttura. Per le aziende che non vogliono gestire autonomamente plugin di backup, pianificazioni, credenziali di archiviazione e regole di avviso, i backup dell’hosting gestito sono la soluzione più tranquilla. Su kodu.cloud, questo tipo di attività operative può essere gestito insieme al monitoraggio del server e all’assistenza, invece di lasciarlo come promemoria mensile che nessuno gradisce.

Backup a livello di server

Un VPS o un server dedicato ti offre un maggiore controllo. Puoi usare attività pianificate per esportare i database, archiviare i file dell’applicazione, crittografare il risultato e trasferirlo a una destinazione di archiviazione indipendente. Sviluppatori e agenzie spesso preferiscono questo metodo perché è possibile adattare pianificazioni, criteri di conservazione, esclusioni e registri a ogni sito.

Un maggiore controllo comporta anche maggiori responsabilità. Lo script di backup deve gestire gli errori, lo spazio disponibile su disco, le autorizzazioni, il monitoraggio dello spazio di archiviazione e la documentazione per il ripristino. Un comando pianificato che fallisce silenziosamente per tre settimane è abbastanza comune da meritare attenzione.

Pianifica i backup in base alle esigenze di ripristino

Comincia con due domande: quanti dati recenti può perdere l’attività e per quanto tempo il sito può restare indisponibile? Questi sono l’obiettivo del punto di ripristino e l’obiettivo del tempo di ripristino. Non è necessario usare le relative sigle durante una riunione, ma dovresti conoscere le risposte.

Un sito vetrina che cambia due volte al mese può essere adeguatamente protetto con backup giornalieri e una conservazione da 14 a 30 giorni. Un sito di agenzia con molti contenuti può trarre vantaggio da backup completi giornalieri e da una copia prima degli aggiornamenti importanti. Un negozio WooCommerce richiede maggiore attenzione: i soli backup giornalieri dei file non bastano se gli ordini vengono registrati durante tutto il giorno.

Per un negozio attivo, valuta backup del database ogni ora o ogni poche ore, backup giornalieri del file system e un backup prima di aggiornare WooCommerce, i plugin di pagamento, i temi o il core di WordPress. Evita di conservare una sola generazione di backup. Se corruzione, spam o malware sono entrati nel sito diversi giorni fa, il backup di ieri potrebbe contenere lo stesso problema.

La conservazione ha un costo. Più punti di ripristino richiedono più spazio di archiviazione, capacità di trasferimento e attività di manutenzione. Una politica ragionevole spesso prevede la conservazione di diverse copie giornaliere recenti, alcune copie settimanali e un numero limitato di copie mensili. I numeri esatti dipendono dal sito e dai requisiti di conformità, ma il principio resta lo stesso: conserva una cronologia sufficiente per ripristinare i dati in caso di un problema scoperto in ritardo.

Conserva almeno una copia al di fuori del server di produzione

Non considerare un backup archiviato accanto al sito web un piano di ripristino di emergenza. Se il disco del server si guasta, un account viene eliminato, il ransomware raggiunge lo spazio di archiviazione montato o un comando di pulizia eseguito con troppa disinvoltura fa danni, i dati di produzione e il backup potrebbero sparire insieme.

Usa uno spazio di archiviazione per i backup separato, con credenziali indipendenti e, preferibilmente, appartenente a un diverso dominio di guasto. Può trattarsi di uno spazio di archiviazione a oggetti, di un server di backup o di un altro provider. Crittografa gli archivi prima del trasferimento se contengono dati dei clienti, informazioni sugli account o file caricati privati. Conserva le chiavi di crittografia e le credenziali di archiviazione separatamente dalla root Web e dal repository.

Il noto principio 3-2-1 è ancora utile: conserva tre copie dei dati importanti, su due tipi di supporto, con una copia fuori sede. Non è necessario farne una cerimonia. È semplicemente un modo per evitare che un singolo evento negativo si trasformi in una perdita totale.

Escludi ciò di cui non è necessario eseguire il backup

Cache di grandi dimensioni, file temporanei, registri di debug, artefatti di distribuzione e cache di immagini generate possono rendere i backup lenti e costosi senza migliorare il ripristino. In genere è ragionevole escludere questi file, purché sia possibile ricrearli in sicurezza.

Fai attenzione ai caricamenti. La directory `wp-content/uploads` contiene comunemente immagini di prodotti, documenti, invii degli utenti e file della libreria multimediale. Di norma dovrebbe rimanere inclusa nel backup. È necessario controllare anche le directory delle applicazioni personalizzate, lo spazio di archiviazione non standard dei plugin e i file esterni alla root di WordPress. Uno sviluppatore potrebbe aver collocato risorse critiche in una posizione inaspettata. Purtroppo, il server non è telepatico.

Prima di definire le esclusioni, confronta il contenuto dell’archivio con ciò di cui l’applicazione ha bisogno dopo un ripristino pulito. Un backup più piccolo è utile solo se consente comunque di ripristinare l’attività.

Rendi visibili gli errori dei backup

Senza segnalazioni, l’automazione è solo parziale. Configura avvisi per processi non riusciti, trasferimenti incompleti, spazio di archiviazione insufficiente, archivi insolitamente piccoli e backup più vecchi di quanto previsto dalla tua politica. L’e-mail è accettabile per un ambiente piccolo, ma un canale di avvisi monitorato è preferibile per i team responsabili di diversi siti cliente.

Controlla i registri dopo la configurazione e dopo modifiche significative a PHP, WordPress, alle versioni del database, alle credenziali di archiviazione o alle autorizzazioni del file system. Un backup riuscito dovrebbe avere un timestamp chiaro, dimensioni nell’intervallo previsto, conferma della destinazione e indicazione dell’esito della conservazione.

Monitora anche lo spazio disponibile su disco nel server di origine. Alcuni strumenti creano l’intero archivio localmente prima di caricarlo. Un server con il disco quasi pieno può avere problemi durante il backup e, allo stesso tempo, causare problemi di prestazioni. Non è la situazione più felice per un disco, ma si può evitare.

Prova i ripristini prima di un’emergenza

È con una prova di ripristino che le dichiarazioni sui backup diventano realtà operative. Almeno ogni trimestre, ripristina una copia recente in un ambiente di staging o in una posizione temporanea separata. Verifica che WordPress si avvii, che il database si connetta, che i contenuti multimediali vengano caricati, che gli utenti possano accedere e che le funzioni aziendali principali funzionino.

Per un negozio online, verifica le pagine dei prodotti, il comportamento del carrello, le impostazioni relative al pagamento, i record degli ordini, la configurazione delle e-mail transazionali e le dipendenze dei plugin di pagamento. Non collocare una copia ripristinata in una posizione da cui possa inviare e-mail reali ai clienti o accettare pagamenti effettivi. Disattiva prima le e-mail in uscita e le operazioni di pagamento nell’ambiente di test.

Documenta la procedura di ripristino mentre la esegui. Annota dove è conservato il backup, quale database deve essere importato, dove modificare i valori di configurazione e come gestire il DNS o gli URL dell’applicazione. Durante una vera interruzione del servizio, una procedura operativa breve e aggiornata fa risparmiare più tempo della memoria di chiunque.

Proteggi il processo di backup

Usa credenziali di archiviazione dedicate con le sole autorizzazioni necessarie per scrivere e leggere i dati di backup. Attiva l’autenticazione a più fattori per l’account di archiviazione e il pannello di controllo dell’hosting. Mantieni aggiornati WordPress, i plugin, i pacchetti del server e gli strumenti di backup, perché un sito compromesso può prendere di mira anche le credenziali di backup accessibili.

Se i backup sono crittografati, prova a decrittografarli durante le esercitazioni di ripristino. Un archivio crittografato senza la chiave corretta è perfettamente sicuro e perfettamente inutile. Conserva le istruzioni per il ripristino in una posizione protetta, accessibile anche se il server di produzione non lo è.

I backup automatizzati dovrebbero ridurre il tuo carico di lavoro, non nascondere i rischi dietro un indicatore di stato verde. Imposta la pianificazione, conserva copie fuori sede, monitora i processi e fai pratica con il ripristino mentre il servizio è di nuovo tranquillo. Così potrai apportare modifiche a WordPress con molta più sicurezza.

Andres Saar, ingegnere dell’assistenza clienti