57 30/03/2026 07/04/2026 8 min

Esportazione e importazione sicura di database MySQL e MariaDB

Quando si lavora con MySQL o MariaDB, l’operazione più comune e più delicata è il trasferimento di un database da un server all’altro, oppure il ripristino dopo un guasto. In teoria è un gesto semplice: esporti, copi, importi. In pratica, la differenza tra una procedura pulita e un disastro sta nei dettagli: versione del server, motore di storage, set di caratteri, dimensione dei dati, privilegi dell’utente, compatibilità degli oggetti SQL, e soprattutto verifica finale.

Questa guida nasce per chi deve fare il lavoro davvero, non per chi vuole solo una sintassi da incollare. L’obiettivo è avere una procedura sicura, reversibile e controllabile, adatta a server Linux, hosting condiviso, VPS e ambienti con cPanel, Plesk o accesso SSH. L’idea di fondo è semplice: prima proteggi i dati, poi esegui l’export, poi importi in modo controllato, e solo alla fine validi il risultato.

Prima di iniziare: cosa devi sapere

Prima di esportare o importare un database, raccogli queste informazioni minime:

  • nome del database;
  • utente MySQL/MariaDB coinvolto;
  • dimensione approssimativa del dump;
  • versione del server sorgente e di quello di destinazione;
  • se il database è in uso da un sito o da un’applicazione attiva.

Se il database è collegato a un sito WordPress, a un CRM o a un e-commerce, considera l’operazione come un intervento di manutenzione. Per evitare inconsistenze, è meglio mettere temporaneamente il sito in manutenzione o bloccare le scritture durante l’export, soprattutto se il traffico è alto o se ci sono ordini, messaggi o modifiche continue.

Se il database è piccolo e il sito è fermo, puoi operare in modo più semplice. Se invece è grande o molto attivo, conviene seguire una procedura con backup, verifica e piano di rollback.

Principio corretto: backup prima, export poi, import controllato

Il punto più importante è non confondere backup ed export. Un export è una copia logica del database, utile per migrazione e ripristino selettivo. Un backup completo include anche la possibilità di tornare indietro con un controllo affidabile. Prima di toccare il database di destinazione, conserva sempre una copia del contenuto attuale, anche se pensi di sovrascriverlo del tutto.

La regola pratica è questa:

  1. verifica lo stato del database sorgente e di quello di destinazione;
  2. esegui un export coerente e verificabile;
  3. salva il file dump in un luogo sicuro;
  4. importa in un database vuoto o preparato appositamente;
  5. controlla tabelle, dati e applicazione collegata;
  6. tieni pronto un rollback con il dump precedente.

Metodo più semplice: phpMyAdmin o pannello hosting

Se lavori da cPanel, Plesk o un pannello simile, l’approccio più comodo è usare l’interfaccia grafica. È spesso la scelta migliore per database piccoli o medi, perché riduce gli errori di comando e permette di gestire esportazione e importazione senza terminale.

Esportazione da phpMyAdmin

  1. Apri phpMyAdmin dal pannello hosting.
  2. Seleziona il database corretto nel menu laterale.
  3. Vai su Esporta.
  4. Scegli il formato SQL.
  5. Per un export affidabile, usa il metodo Personalizzato se disponibile.
  6. Attiva l’opzione per includere DROP TABLE / DROP VIEW solo se sai che il dump sarà usato per ripristinare un database vuoto o da sovrascrivere.
  7. Verifica che siano inclusi tabelle, routine, trigger e event se il database li usa.
  8. Scarica il file compresso, se il pannello lo consente, per risparmiare spazio e velocizzare il trasferimento.

Esito atteso: ottieni un file `.sql` o `.sql.gz` coerente e di dimensione plausibile rispetto al database originale.

Importazione da phpMyAdmin

  1. Crea prima il database di destinazione, se non esiste.
  2. Crea o assegna l’utente corretto con i privilegi necessari.
  3. Apri phpMyAdmin e seleziona il database di destinazione.
  4. Vai su Importa.
  5. Carica il file dump.
  6. Controlla il limite di upload del pannello se il file è grande.
  7. Avvia l’importazione e attendi il messaggio di successo.

Esito atteso: nessun errore di sintassi, nessun timeout, e il numero di tabelle importate corrisponde a quello del database sorgente.

Se il file è troppo grande per il pannello, usa il terminale oppure spezza il dump in modo controllato. L’import da interfaccia grafica è comodo, ma non è il metodo più robusto per database pesanti.

Metodo più affidabile: export e import da terminale

Quando il database è importante, grande o in produzione, il terminale resta la strada più sicura e verificabile. Con SSH puoi controllare meglio i parametri, comprimere il dump, loggare gli errori e riprendere il lavoro con più precisione.

Export sicuro con `mysqldump`

Il comando base per esportare un database è questo:

mysqldump -u NOMEUTENTE -p NOME_DATABASE > backup.sql

Questo crea un dump SQL semplice. Per un export più robusto, soprattutto su database attivi, conviene usare una versione più completa:

mysqldump -u NOMEUTENTE -p 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --default-character-set=utf8mb4 
  NOME_DATABASE | gzip > backup.sql.gz

Perché questa forma è preferibile:

  • --single-transaction riduce il rischio di inconsistenze su tabelle InnoDB;
  • --routines, --triggers ed --events includono oggetti spesso dimenticati;
  • --default-character-set=utf8mb4 aiuta con emoji e caratteri speciali;
  • la compressione con gzip riduce spazio e tempo di trasferimento.

Esito atteso: un file compresso presente sul server, con dimensione coerente e senza errori stampati a schermo.

Verifiche immediate dopo l’export

  1. Controlla che il file esista e non sia vuoto: un dump da 0 byte è quasi sempre un fallimento.
  2. Verifica la dimensione del file rispetto al database originale: un dump troppo piccolo segnala spesso un export incompleto.
  3. Se usi gzip, prova a leggere l’intestazione o a testare l’integrità del file.
ls -lh backup.sql.gz
gzip -t backup.sql.gz

Esito atteso: il file è presente, ha una dimensione plausibile e il test gzip non restituisce errori.

Import sicuro con `mysql`

Prima di importare, assicurati che il database di destinazione esista. Se necessario, crealo da pannello o da terminale. Poi importa con:

gunzip -c backup.sql.gz | mysql -u NOMEUTENTE -p NOME_DATABASE

Se il dump non è compresso:

mysql -u NOMEUTENTE -p NOME_DATABASE < backup.sql

Esito atteso: il comando termina senza errori di sintassi o di permessi e il database contiene le tabelle previste.

Gestione corretta dei privilegi

Un errore molto comune è importare con un utente che non ha i privilegi giusti. In alcuni casi l’import sembra partire e poi si interrompe a metà, lasciando il database in stato parziale. Per questo conviene verificare prima i permessi dell’utente.

Il profilo minimo utile per un import completo deve includere almeno i privilegi necessari su quel database specifico. Se l’utente è usato da una web app, evita di dargli privilegi globali inutili. Il principio corretto è il least privilege: solo ciò che serve, sul database giusto, e niente di più.

Se lavori in cPanel o Plesk, assegna l’utente al database e verifica che abbia i permessi richiesti. Se lavori da MySQL/MariaDB, controlla che l’utente esista e che il database di destinazione sia quello corretto prima di procedere.

Attenzione a charset, collation e compatibilità

Molti problemi nascosti nascono da differenze di charset e collation. Un database creato anni fa può usare `latin1`, mentre il nuovo ambiente usa `utf8mb4`. In questi casi l’import può riuscire, ma i dati possono risultare corrotti o visualizzati male.

Prima della migrazione, confronta questi elementi:

  • charset del database;
  • collation delle tabelle;
  • versione MySQL/MariaDB;
  • eventuali funzioni, trigger o procedure compatibili solo con una versione specifica.

Se il database sorgente usa impostazioni vecchie, valuta una normalizzazione solo dopo aver eseguito un backup integro. Non cambiare charset “al volo” durante l’import se non sai esattamente come reagirà l’applicazione.

Per un sito moderno, la scelta più sicura è normalmente `utf8mb4`, ma la conversione va testata in staging prima di applicarla in produzione.

Database grandi: come evitare timeout e import incompleti

Con database di grandi dimensioni, i problemi più frequenti sono timeout, limiti di memoria, upload limitato, connessioni interrotte e blocchi sul web server. In questi casi il terminale è quasi sempre la scelta migliore.

Se l’import è molto grande, segui queste regole:

  1. comprimere il dump con gzip per ridurre il peso del file;
  2. importare da SSH invece che da browser;
  3. usare un database vuoto, non uno già pieno di dati;
  4. monitorare lo spazio disco prima e durante l’operazione;
  5. evitare di lanciare import in orari di alto traffico.

Se il server è poco potente, controlla anche CPU, RAM e I/O disco. Un import lento non è sempre un problema del file: può dipendere dal server che non regge il carico o da tabelle con indici pesanti.

Importazione in ambiente di produzione: procedura prudente

Se il database alimenta un sito in produzione, non sovrascriverlo alla cieca. La procedura prudente è questa:

  1. salva un dump del database attuale prima di toccarlo;
  2. verifica che il dump sorgente sia integro;
  3. metti il sito in manutenzione o blocca le scritture;
  4. importa nel database di destinazione;
  5. esegui controlli funzionali sul sito o sull’applicazione;
  6. solo dopo riapri il servizio.

Se qualcosa va storto, il rollback deve essere semplice: ripristina il dump precedente e riporta online la versione stabile. Questo è il motivo per cui il backup del database attuale è obbligatorio, non facoltativo.

Controlli post-import fondamentali

Dopo l’import, non fermarti al messaggio “Query OK”. Devi verificare il contenuto e il comportamento applicativo. I controlli minimi sono questi:

  1. numero delle tabelle presenti;
  2. presenza dei record principali;
  3. assenza di errori nei log dell’applicazione;
  4. corretto accesso al sito o al servizio che usa il database;
  5. coerenza di caratteri speciali, date e dati numerici.

Se si tratta di WordPress, controlla che il sito si apra, che il login funzioni e che i contenuti principali siano leggibili. Se si tratta di un e-commerce, verifica almeno homepage, catalogo, carrello e checkout. Se si tratta di un gestionale, apri le pagine o i moduli più usati.

Per una verifica SQL di base, puoi controllare il numero di tabelle e qualche dato chiave. Per esempio:

mysql -u NOMEUTENTE -p -e