Backup WordPress che si ripristinano davvero

Il backup WordPress tipico fallisce proprio quando serve. Un plugin scrive un file zip in wp-content, nello stesso account di hosting del sito. Se un aggressore, un ransomware o la sospensione dell'account colpisce il sito, quella copia se ne va insieme a lui.

Un backup vale qualcosa solo se da esso si riesce a ripristinare. Questa guida spiega cosa includere, dove conservare le copie, con quale frequenza eseguirle, come testare un ripristino e come scegliere un punto di ripristino pulito dopo un attacco.

Cosa deve contenere un backup WordPress: file e database

Un sito WordPress ha due metà e servono entrambe. Il database contiene articoli, pagine, utenti e hash delle password, impostazioni, ordini WooCommerce e invii dei moduli. Si pensi a un plugin per moduli di contatto che salva le richieste nel database: un backup di soli file perde ogni richiesta, mentre un backup del solo database riporta le voci senza il plugin che le legge.

I file necessari sono wp-content (upload, plugin, temi), wp-config.php e .htaccess o la configurazione del server. Il core di WordPress si può scaricare di nuovo, ma solo se si sa quale versione era in uso.

Dalla root di WordPress, con WP-CLI:

# Esportazione del database, scritta fuori dalla web root
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql

# File: wp-content, wp-config.php e .htaccess (esclusi cache e vecchie cartelle di backup)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/backups' \
    -czf ~/backups/files-$(date +%F).tar.gz \
    wp-content wp-config.php .htaccess

# Registra le versioni, così core, plugin e temi si reinstallano da fonti ufficiali
wp core version > ~/backups/versions-$(date +%F).txt
wp plugin list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt
wp theme list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt

Sostituite wp-content/backups con la cartella usata dal vostro plugin di backup. Su nginx non esiste .htaccess: toglietelo dal comando e salvate invece la configurazione del server. I backup dentro i backup fanno crescere ogni archivio. I comandi db di WP-CLI sono documentati su WordPress.org.

La regola 3-2-1 e perché un backup nell'account di hosting non conta

La regola prevede tre copie dei dati, su due tipi diversi di supporto, con una copia off-site. Il sito attivo vale come una copia. Un backup nello stesso account di hosting è la seconda, ma ha lo stesso login, lo stesso server e lo stesso fornitore del sito.

Chi riesce a scrivere sul sito di solito può cancellare anche quella copia. Un ransomware che cifra la web root cifra anche lo zip accanto. La sospensione dell'account o il guasto dell'host portano via entrambi insieme. Gli snapshot dell'host sono utili e rapidi da ripristinare, ma restano un'unica copia che non controllate.

La terza copia è quella che conta. Deve finire su uno storage presso un fornitore diverso, con credenziali separate che non siano salvate sul web server in una forma che consenta la cancellazione. Due impostazioni fanno una grande differenza:

• Versioning o immutabilità. Molti servizi di object storage offrono versioning, object lock o un blocco di conservazione lato fornitore. Il versioning conserva le copie precedenti, ma chi ha i permessi di cancellazione può comunque rimuoverle. Un blocco nella modalità più rigida (compliance) impedisce a chiunque, voi compresi, di cancellare o sovrascrivere un backup fino alla scadenza del periodo.
• Credenziali di sola scrittura per il job di backup. Se la chiave sul server può solo caricare file e il versioning o un blocco mantiene le copie precedenti, un aggressore che la sottrae non può cancellare né sovrascrivere il vostro storico.

Con quale frequenza eseguire i backup e per quanto tempo conservarli

La frequenza dipende dalla velocità con cui cambiano i dati. Un sito vetrina modificato una volta al mese si accontenta di backup settimanali. Un negozio che riceve ordini ogni giorno richiede backup del database almeno giornalieri, spesso più frequenti. I file cambiano di solito meno del database e possono quindi seguire una pianificazione separata.

Il periodo di conservazione è un compromesso. Le compromissioni vengono spesso scoperte settimane dopo l'inizio. Se si conservano solo sette giorni di copie, ognuna potrebbe già contenere la backdoor. D'altro canto, i vecchi backup mantengono in vita dati personali, compresi gli account che gli utenti hanno chiesto di cancellare.

Stabilite una finestra di conservazione fissa e una rotazione, per esempio copie giornaliere per qualche settimana più copie mensili per un periodo limitato. Mettetela per iscritto. Quella pianificazione documentata aiuta anche con le richieste di cancellazione: i dati scompaiono dai backup alla scadenza delle copie e, fino ad allora, vi assicurate che non vengano ripristinati né utilizzati. Riscrivere gli archivi a ogni richiesta è raramente praticabile; consultate le indicazioni della vostra autorità di controllo sui backup.

I backup contengono dati personali: cifratura, accessi e contratti

Un backup WordPress contiene account utente, hash delle password, dati di clienti e ordini, invii dei moduli. Perderlo è grave quanto perdere il database in produzione.

• Cifrate i dati in transito e a riposo. La cifratura è una delle misure citate nell'art. 32, par. 1, lett. a) GDPR. Conservate la chiave in un luogo diverso dallo storage che protegge.
• Limitate gli accessi. Solo chi esegue i ripristini deve poter scaricare i backup. Eliminate i vecchi link di download condivisi e gli account utente scaduti sullo storage.
• Firmate i contratti. Un fornitore di storage per backup o un'agenzia che conserva copie è un responsabile del trattamento ai sensi dell'art. 28 e richiede un accordo sul trattamento dei dati.

Un backup non cifrato, smarrito o raggiungibile pubblicamente può costituire di per sé una violazione dei dati personali. In tal caso consultate la guida alla notifica entro 72 ore.

Provate un ripristino prima di averne bisogno

Ripristinate su un sito di staging o su una copia locale, mai sopra il sito in produzione. Usate la copia off-site, non quella locale più comoda, perché dopo un incidente vero avrete a disposizione proprio la prima.

# In una web root vuota su staging; WP_VERSION proviene dal file delle versioni
wp core download --version="$WP_VERSION" --skip-content
tar -xzf files-2026-10-23.tar.gz
# Modificate wp-config.php: credenziali del database di staging, poi:
wp db import db-2026-10-23.sql
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid
wp option update blog_public 0

blog_public 0 chiede ai motori di ricerca solo di restare alla larga. Proteggete lo staging anche con autenticazione HTTP. Impedite che invii email a clienti reali o richiami webhook di pagamento, e valutate define( 'DISABLE_WP_CRON', true ); per la durata del test.

Poi verificate:

• Il login di amministrazione funziona
• L'invio di un modulo va a buon fine
• L'ordine o l'articolo più recente è presente
• Immagini e download si caricano
• L'elenco dei plugin e le versioni corrispondono al vostro registro
• Il tempo totale dall'avvio al sito funzionante è annotato

Quel tempo è il vostro vero tempo di ripristino, spesso più lungo di quanto si pensi. Registrate la data, il backup usato, l'esito e gli eventuali problemi riscontrati. Un backup mai ripristinato non dimostra nulla né a voi né a chi vi chieda come rispettate l'art. 32, par. 1, lett. c) e d), o l'obbligo di responsabilizzazione dell'art. 5, par. 2.

Ripristino dopo un attacco: trovare l'ultimo punto pulito

Non ripristinate alla cieca il backup più recente: probabilmente contiene la backdoor. Il più vecchio può essere pulito ma mancare di settimane di ordini. Prima di modificare qualsiasi cosa, conservate una copia dello stato infetto per poter indagare in seguito.

Poi stimate quando è iniziata la compromissione. Esaminate i log del server e degli accessi, le date di modifica dei file, gli utenti amministratori che non riconoscete e i file che differiscono da un backup più vecchio. Quindi scegliete un backup precedente a quella data. Una baseline di integrità dei file aiuta in questo caso. Il plugin Security Audit & Compliance ne registra una e segnala i file modificati e gli indicatori di compromissione, restringendo il momento in cui le cose sono cambiate. Non crea né ripristina backup.

Un approccio più pulito di un ripristino completo:

1. Reinstallate core, plugin e temi da fonti ufficiali, a versioni note.
2. Prelevate dal punto pulito solo gli upload e il database. Controllate che negli upload non ci siano file PHP (come trovare le web shell negli upload).
3. Verificate nel database la presenza di amministratori iniettati (wp user list --role=administrator) e di contenuti spam.
4. Reinserite o migrate gli ordini e i dati creati dopo quel punto.

Un ripristino non chiude la falla. Prima di rimettere online il sito, aggiornate o rimuovete il componente vulnerabile e ruotate tutte le password, le chiavi e i salt. Altrimenti verrete attaccati di nuovo dalla stessa strada. La procedura completa è nel nostro piano di rimozione del malware, mentre la verifica dei checksum del core conferma che il core è pulito.

Cosa si aspettano GDPR e NIS2 dai vostri backup

L'art. 5, par. 1, lett. f) del GDPR richiede una sicurezza adeguata, comprese integrità e riservatezza. L'art. 32, par. 1, lett. c) chiede la capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati personali in caso di incidente, e la lett. d) chiede di testare regolarmente le misure adottate. Perdere i dati dei clienti senza poterli ripristinare può configurare una violazione della disponibilità.

Per i soggetti che rientrano nell'ambito della normativa nazionale, l'art. 21, par. 2, lett. c) della direttiva NIS2 cita la continuità operativa, compresi la gestione dei backup e il ripristino in caso di disastro. Anche se la NIS2 non vi riguarda direttamente, i vostri clienti soggetti alla NIS2 potrebbero chiedervi evidenze in quanto fornitori o agenzia. La nostra panoramica sull'art. 32 GDPR offre il quadro più ampio.

Tenete un registro dei backup di una pagina: cosa viene salvato, dove, con quale frequenza, la finestra di conservazione, la cifratura, chi ha accesso, la data e l'esito dell'ultimo test di ripristino. Il passo successivo è pianificare questa settimana il primo test di ripristino, usando la copia off-site.

FAQ

Il backup giornaliero del mio hosting è sufficiente?

Di solito no, da solo. È una sola copia, conservata presso lo stesso fornitore e spesso per un periodo breve. Verificate per quanto tempo viene mantenuta e aggiungete una copia off-site sotto il vostro controllo.

Devo includere nel backup il core di WordPress?

Non è necessario se registrate le versioni di core, plugin e temi. La reinstallazione da WordPress.org fornisce inoltre file del core noti e integri.

Come gestisco una richiesta di cancellazione quando i dati della persona sono nei backup?

Cancellate i dati dal sito in produzione e fate affidamento sulla finestra di conservazione documentata per i backup. Se mai doveste ripristinare, assicuratevi che i dati di quella persona non vengano reinseriti nel sito attivo.

Con quale frequenza va testato un ripristino?

Regolarmente, e sempre dopo modifiche rilevanti all'hosting, al sito o allo strumento di backup. Scegliete un intervallo che rispetterete davvero e registrate ogni test.

Questo articolo è un'informazione di carattere generale e non costituisce consulenza legale.