1 14/04/2026 11 min

Se devi salvare il database di WordPress e non vuoi passare da phpMyAdmin, cPanel ti dà un percorso più pulito: meno click, meno rischio di esportare il database sbagliato e più controllo su file, compressione e ripristino. Il punto non è “fare un dump” e basta; il punto è ottenere un backup verificabile, ripetibile e, se serve, ripristinabile senza scoprire a posteriori che l’export era incompleto o che il database era già corrotto prima del salvataggio.

Qui la scelta pratica è semplice: se hai accesso a cPanel, puoi usare Backup o Backup Wizard per esportare il database MySQL/MariaDB di WordPress in formato compresso o SQL. Se hai anche accesso SSH, puoi affiancare un dump da shell per avere un controllo più fine. La differenza tra le due strade è operativa: cPanel è spesso la via più rapida per un operatore di hosting; la shell è più trasparente quando vuoi automatizzare o verificare ogni passaggio.

Quando conviene evitare phpMyAdmin

phpMyAdmin è comodo, ma non sempre è la scelta migliore. Su database grandi può andare in timeout, può essere limitato da PHP memory_limit o max_execution_time e può produrre export parziali se il browser interrompe la sessione. In un contesto WordPress, questo si traduce in backup poco affidabili proprio quando il sito è cresciuto abbastanza da richiederli davvero.

Con cPanel hai un vantaggio concreto: il processo di backup è lato server, quindi non dipende dal browser dell’operatore. In più, se il provider ha abilitato le funzioni di backup del pannello, spesso trovi una copia coerente dei dati senza dover gestire manualmente ogni opzione di esportazione.

Prima di fare il backup: identifica il database giusto

WordPress non “sa” di essere WordPress: il collegamento al database è nel file `wp-config.php`. Prima di esportare, devi leggere i parametri corretti e non fidarti del nome del sito o della directory. In ambienti con più installazioni è l’errore più comune: si salva il database del sito A mentre si stava mettendo in sicurezza il sito B.

Apri `wp-config.php` e verifica questi campi:

define( 'DB_NAME', 'nome_database' );
define( 'DB_USER', 'utente_database' );
define( 'DB_PASSWORD', 'password_database' );
define( 'DB_HOST', 'localhost' );

Se hai accesso SSH, puoi leggere il file senza modificarlo:

cd /home/utente/public_html
grep -nE "DB_NAME|DB_USER|DB_HOST" wp-config.php

Se il dominio punta a più installazioni o usi staging, controlla anche il prefisso delle tabelle con `table_prefix`. Non cambia il nome del database, ma aiuta a capire se stai guardando l’istanza giusta quando il pannello mostra più risorse simili.

Backup del database da cPanel: percorso rapido

In molti pannelli cPanel trovi una voce chiamata Backup oppure Backup Wizard. Il percorso può cambiare leggermente in base al provider, ma la logica è la stessa: esportare solo il database o un backup completo dell’account. Per il solo WordPress, il database è la parte che ti serve per contenuti, utenti, impostazioni, menu, revisioni e plugin che salvano dati in tabelle proprie.

  1. Accedi a cPanel con l’utente dell’hosting.
  2. Apri Backup o Backup Wizard.
  3. Scegli il backup del database MySQL.
  4. Seleziona il database corretto usando il nome trovato in `wp-config.php`.
  5. Scarica il file generato, che di solito è `.sql`, `.sql.gz` o un archivio compresso equivalente.

Se il pannello propone più database, non fermarti al nome “simile”: verifica il nome esatto e, se disponibile, la dimensione. Un database WordPress con poche centinaia di MB è normale in siti con cronologia, log di plugin o tabelle di cache persistente; un database da pochi KB di solito non è quello giusto, mentre un database enorme e inatteso può indicare tabelle residue di plugin rimossi male.

Alcuni provider mostrano anche un’opzione per il backup completo dell’account. È utile come snapshot d’emergenza, ma non va confuso con il backup logico del database. Per il restore selettivo, il dump del solo database è più pratico: scarichi meno dati, riduci i tempi e rendi più semplice una verifica puntuale.

Backup via shell con mysqldump: più controllo, meno sorprese

Se hai SSH, `mysqldump` resta la strada più trasparente. Ti permette di scegliere formato, compressione e consistenza. Per WordPress, un dump coerente è in genere sufficiente: è un database transazionale e il contenuto non richiede snapshot a livello filesystem, salvo plugin che salvano file esterni o allegati non ancora sincronizzati.

Comando base:

mysqldump -u DB_USER -p DB_NAME > backup-wordpress.sql

Versione più robusta, con opzioni utili per WordPress:

mysqldump -u DB_USER -p \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --add-drop-table \
  DB_NAME | gzip > backup-wordpress.sql.gz

Le opzioni qui sopra hanno un senso pratico:

  • --single-transaction riduce il rischio di inconsistenza sui motori InnoDB senza bloccare le tabelle per tutto il dump.
  • --quick evita di caricare troppo in memoria i risultati.
  • --routines e --triggers servono se il database contiene oggetti aggiuntivi oltre alle tabelle standard.
  • --add-drop-table semplifica il restore, perché il file contiene la rimozione preventiva delle tabelle esistenti.

Se il database è grande, la compressione al volo con `gzip` è quasi sempre una buona idea. Riduce lo spazio occupato e spesso accelera anche il trasferimento se devi scaricare il file via SFTP o SCP. Il costo CPU esiste, ma su host moderni è quasi sempre accettabile rispetto al beneficio operativo.

Se vuoi evitare di mettere la password nel comando shell, usa un file di configurazione utente con permessi stretti. Esempio con `~/.my.cnf`:

[client]
user=DB_USER
password=PASSWORD
host=localhost

Imposta i permessi corretti e verifica che il file non sia leggibile da altri utenti del sistema:

chmod 600 ~/.my.cnf
ls -l ~/.my.cnf

Qui il punto sicurezza è semplice: le credenziali non devono finire nella history della shell, nei log del terminale o in uno script condiviso. Se un accesso è temporaneo, ruota le credenziali dopo l’operazione o usa un account con privilegi minimi sul solo database da esportare.

Verifica del backup: non basta che il file esista

Un backup che non si apre è solo un file scaricato. La verifica minima è tripla: il file esiste, ha dimensione plausibile e contiene dati SQL coerenti. Se salti questo passaggio, ti accorgi del problema solo durante il restore, che è il momento peggiore per scoprire un export troncato.

  1. Controlla la dimensione del file.
  2. Verifica il tipo di archivio.
  3. Fai un test di integrità e una prova di lettura.
ls -lh backup-wordpress.sql.gz
file backup-wordpress.sql.gz
gzip -t backup-wordpress.sql.gz

Se hai un dump `.sql` non compresso, controlla almeno le prime righe e la presenza di istruzioni tipiche di dump MySQL:

head -n 20 backup-wordpress.sql
grep -n "CREATE TABLE\|INSERT INTO\|DROP TABLE" backup-wordpress.sql | head

Per una verifica più concreta, puoi importare il backup in un database di test o in uno staging. È il controllo che vale di più, perché dimostra che il file non solo esiste, ma è ripristinabile. Se non hai uno staging, anche un database locale temporaneo è meglio di nessun test.

Ripristino del database: procedura prudente

Il restore è l’operazione in cui si fanno i danni più grossi, quindi va trattato come change controllato. Prima di importare, crea una copia del database attuale o esportalo a sua volta. Così, se il backup che stai ripristinando contiene dati vecchi o incompleti, puoi tornare indietro senza dover ricostruire a mano.

  1. Metti il sito in manutenzione, se il restore è su produzione.
  2. Esegui un backup del database attuale.
  3. Svuota o ricrea il database di destinazione solo se sai cosa stai facendo.
  4. Importa il dump.
  5. Verifica login, homepage, articoli, media e funzionalità critiche del sito.

Esempio di import da shell:

gunzip -c backup-wordpress.sql.gz | mysql -u DB_USER -p DB_NAME

Se il database contiene già tabelle e vuoi evitare conflitti, il restore deve essere pianificato. Il file con `--add-drop-table` aiuta, ma non sostituisce una verifica preventiva. In ambienti con plugin e tabelle custom, un import “alla cieca” può sovrascrivere dati recenti, ordini, form submission o log applicativi.

Da cPanel, il restore può essere disponibile nello stesso pannello di backup oppure tramite phpMyAdmin, ma qui il requisito era evitare phpMyAdmin. Se il pannello offre un ripristino database nativo, usalo. Se non c’è, la shell resta la via più affidabile. In assenza di SSH, valuta un ticket al provider: forzare procedure manuali con strumenti incompleti è la via più corta per un incidente.

Backup automatici: il dettaglio che fa risparmiare tempo

Un backup manuale fatto bene è utile, ma non basta se devi proteggere un sito vivo. Il vero salto di qualità è automatizzare. Se il piano hosting lo consente, programma dump giornalieri o notturni e conserva una rotazione minima: per esempio 7 copie giornaliere e 4 settimanali. Non serve accumulare mesi di file se poi nessuno li verifica.

Con cPanel, alcune installazioni includono strumenti di backup programmato; in altri casi puoi usare un cron job via shell. Esempio di script semplice:

#!/bin/bash
set -euo pipefail
DATA=$(date +%F)
DEST=/home/utente/backups
DB_NAME=nome_database
mysqldump --single-transaction --quick --routines --triggers "$DB_NAME" | gzip > "$DEST/$DB_NAME-$DATA.sql.gz"
find "$DEST" -name "$DB_NAME-*.sql.gz" -mtime +14 -delete

Qui c’è un aspetto importante: la rotazione deve essere coerente con la tua retention policy. Se cancelli i file vecchi, fallo con una regola chiara e documentata. Se il sito è critico, conserva almeno una copia fuori dall’account hosting, perché un problema sull’account può coinvolgere anche i backup locali.

Se vuoi spingere il livello di affidabilità, copia il dump su storage esterno o object storage. Il backup che vive nello stesso spazio del sito riduce il rischio solo a metà: protegge da errori applicativi, non da guasti dell’account, sospensioni o compromissioni del pannello.

Errori tipici e come leggerli

Quando il backup fallisce, il messaggio d’errore spesso è più utile del file stesso. Alcuni casi ricorrenti sono facili da riconoscere.

  • Access denied: utente o password del database errati, oppure privilegi insufficienti.
  • Unknown database: il nome letto in `wp-config.php` non corrisponde a quello reale.
  • MySQL server has gone away: dump interrotto per timeout, connessione o limiti lato server.
  • No space left on device: spazio disco insufficiente durante la generazione o la compressione del file.
  • Corrupted archive: file incompleto o trasferimento interrotto.

Per il primo e il secondo caso, la verifica parte sempre da `wp-config.php` e dalle credenziali effettive. Per il terzo, l’azione correttiva è spesso usare `--single-transaction` e compressione, oppure spostare il dump fuori da una sessione fragile. Per il quarto, serve liberare spazio prima di ripetere il backup. Per il quinto, il problema è quasi sempre nel trasferimento o nella chiusura anticipata del processo.

Strategia pratica per WordPress in hosting condiviso

In hosting condiviso bisogna lavorare con i vincoli del pannello, non contro di essi. La strategia più equilibrata è questa: identificare il database dal `wp-config.php`, esportarlo da cPanel se disponibile, verificare il file scaricato, conservarne una copia esterna e testare il restore almeno su staging. In parallelo, se l’hosting consente SSH, tenere pronto un dump da shell come piano B.

Questo approccio ha un vantaggio concreto: riduce la dipendenza da un singolo strumento. Se cPanel ha limiti temporanei, la shell risolve. Se SSH non è disponibile, il pannello resta utilizzabile. Se il database cresce, la procedura resta la stessa e non devi cambiare abitudini ogni volta che il sito supera una certa dimensione.

Cosa controllare dopo il backup

Dopo il backup, fai sempre questi controlli minimi:

  1. Il file è presente nel percorso previsto o è stato scaricato correttamente.
  2. La dimensione del file è coerente con il database originale.
  3. Il file compresso passa il test di integrità.
  4. Il dump contiene tabelle WordPress e non è vuoto.
  5. Esiste una copia esterna o comunque separata dall’account principale.

Se devi documentare la procedura per un team, annota sempre nome database, data backup, metodo usato, percorso del file e risultato della verifica. È il minimo per evitare che tra due settimane qualcuno debba ricostruire tutto a memoria. Nei sistemi piccoli sembra eccessivo; nei sistemi piccoli, però, è proprio la memoria umana a essere il primo punto debole.

Conclusione operativa

Fare il backup del database WordPress senza phpMyAdmin con cPanel non è una deviazione, è spesso la scelta più solida. Il flusso corretto è: individua il database nel `wp-config.php`, esporta dal pannello o da shell, comprimi se serve, verifica il file e conserva almeno una copia fuori dall’hosting. Se poi vuoi un livello davvero utile in produzione, automatizza e testa il restore. Un backup non verificato è solo una speranza con estensione `.sql`.