Come importare ed esportare un database con phpMyAdmin

Con phpMyAdmin importare o esportare un database è comodo, ma solo se si capisce bene cosa sta succedendo dietro l’interfaccia. Il punto non è premere “Esporta” o “Importa”: il punto è scegliere il formato giusto, evitare errori di encoding, non superare i limiti di PHP e avere sempre un piano di rollback. Se il database è piccolo, l’operazione è banale. Se il database cresce, entrano in gioco compressione, timeout, dimensione massima del file, blocchi di tabelle e coerenza dei dati.

La regola pratica è semplice: esporta sempre una copia completa prima di importare, verifica il charset, controlla i limiti del server web e non dare per scontato che un dump “riuscito” sia anche un dump “ripristinabile” senza errori. phpMyAdmin fa il suo lavoro, ma non corregge un ambiente configurato male.

Quando usare phpMyAdmin e quando no

phpMyAdmin è adatto per database piccoli e medi, operazioni manuali, verifiche veloci e trasferimenti tra ambienti dove hai accesso al pannello web ma non alla shell. È utile anche quando devi mostrare a un cliente o a un collega il contenuto di un database senza aprire accessi SSH.

Non è invece la scelta migliore per dump molto grandi, restore lunghi, migrazioni critiche o ambienti con limiti stretti di memoria e timeout. In quei casi mysqldump e mysql da terminale restano più affidabili, perché puoi controllare meglio compressione, streaming e log degli errori.

Se devi lavorare in produzione, il criterio è questo: phpMyAdmin va bene come interfaccia operativa, ma non deve diventare l’unico metodo di recovery. Il backup vero va sempre verificato anche fuori dal pannello.

Prima di esportare: controlli minimi che evitano problemi dopo

Prima dell’esportazione conviene verificare tre cose: dimensione del database, charset/collation e modalità di accesso. Se il database è in utf8mb4 ma esporti o importi con impostazioni incoerenti, rischi caratteri corrotti, emoji perse o errori su colonne troppo lunghe.

Da shell, se hai accesso al server MySQL/MariaDB, puoi farti un’idea rapida della dimensione:

mysql -u root -p -e "SELECT table_schema AS db, ROUND(SUM(data_length+index_length)/1024/1024,2) AS size_mb FROM information_schema.tables WHERE table_schema='nome_database' GROUP BY table_schema;"

Se il risultato è nell’ordine di pochi megabyte, l’interfaccia web di solito basta. Se sei sopra qualche centinaio di megabyte, l’export via browser può diventare fragile per timeout o limiti di upload/download.

Controlla anche i limiti PHP del server che ospita phpMyAdmin. I parametri più rilevanti sono upload_max_filesize, post_max_size, max_execution_time e, a seconda dello stack, anche il timeout del proxy o del web server. Se questi valori sono troppo bassi, l’import fallisce a metà senza un messaggio sempre chiarissimo.

Esportare un database con phpMyAdmin

La schermata di esportazione di phpMyAdmin offre in genere una modalità rapida e una personalizzata. Per un backup serio, la modalità personalizzata è quella che vale la pena usare, perché ti consente di scegliere tabelle, formato e opzioni SQL più adatte al ripristino.

In pratica, l’ordine consigliato è questo:

1. Seleziona il database.
2. Apri la scheda Esporta.
3. Scegli Personalizzato, non “Rapido”, se il dump deve servire davvero a un restore.
4. Seleziona il formato SQL.
5. Imposta compressione gzip se il file è grande e devi scaricarlo via browser.
6. Verifica che siano incluse tabelle, struttura e dati.
7. Se il database usa caratteri speciali, controlla il charset dell’output.

Quando esporti in SQL, alcune opzioni sono più utili di altre. Le clausole DROP TABLE / VIEW / PROCEDURE / FUNCTION possono essere comode per ripristini puliti in ambienti di test, ma in produzione vanno usate con cautela perché rendono il dump più aggressivo. Se vuoi un backup che non faccia danni per errore, meglio mantenere il dump neutro e decidere in fase di import se svuotare prima il database di destinazione.

Se devi spostare il database tra server diversi, assicurati che il dump contenga anche eventuali routine, trigger e eventi. phpMyAdmin può esportarli, ma spesso chi usa l’interfaccia lascia attive solo tabelle e dati, poi scopre dopo il restore che il sito funziona a metà. Un esempio classico è un CMS che si appoggia a trigger o procedure custom: il sito sale, ma alcune funzioni restano rotte.

Per database più grandi, usa la compressione. In phpMyAdmin il file viene spesso offerto come .sql.zip o .sql.gz. Gzip è in genere più compatto e più adatto a file testuali SQL. Il vantaggio è doppio: meno spazio su disco e meno traffico in download.

Se hai accesso alla shell, il confronto con il dump da terminale è utile per capire il contesto. Un export equivalente può essere fatto così:

mysqldump -u root -p --single-transaction --routines --triggers --events nome_database | gzip > nome_database.sql.gz

Questa riga non sostituisce phpMyAdmin, ma ti dice quali elementi dovresti aspettarti nel dump se vuoi un backup veramente completo. --single-transaction aiuta sui motori transazionali, mentre --routines, --triggers ed --events evitano sorprese in fase di restore.

Importare un database: il punto dove si fanno più errori

L’import è la parte delicata. Un file SQL può essere formalmente valido e comunque fallire per limiti di upload, collazioni incompatibili, tabelle già presenti, engine diversi o query troppo lunghe per la configurazione del server. Il fatto che il file si carichi nel browser non significa che il database lo accetti fino in fondo.

La procedura corretta parte sempre dalla destinazione. Prima di importare, apri il database target, verifica che sia vuoto o compatibile con ciò che stai per caricare, e controlla il charset. Se stai ripristinando sopra un database esistente, valuta se fare prima un backup del contenuto attuale. È una misura banale, ma è quella che salva quando il dump importato non è quello giusto.

Passi consigliati:

1. Apri phpMyAdmin e seleziona il database di destinazione.
2. Se necessario, crea il database con la collation corretta, per esempio utf8mb4_unicode_ci o quella richiesta dall’applicazione.
3. Vai su Importa.
4. Carica il file .sql o compresso.
5. Controlla che il formato rilevato sia SQL.
6. Avvia l’import e monitora eventuali errori a schermo.

Se il file è compresso, phpMyAdmin lo decomprime lato server. Questo è comodo, ma aumenta il lavoro sul server web e sulla memoria disponibile. Se l’import si interrompe senza un errore pulito, il sospetto principale è quasi sempre uno tra limite di upload, timeout o memoria PHP insufficiente.

Un controllo utile, quando l’import sembra riuscito ma il sito continua a non funzionare, è verificare il numero di tabelle e qualche record chiave. Ad esempio, confronta il conteggio di tabelle e righe attese con quanto realmente presente:

mysql -u root -p -e "SELECT COUNT(*) AS tables_count FROM information_schema.tables WHERE table_schema='nome_database';"
mysql -u root -p -e "SELECT COUNT(*) AS users_count FROM nome_database.wp_users;"

Se il database è di un CMS, confronta tabelle come utenti, opzioni, contenuti principali e tabelle custom. Un import parziale può sembrare completo in phpMyAdmin, ma lasciare fuori proprio la tabella che serve all’applicazione per autenticarsi o per costruire le impostazioni del sito.

Limiti di PHP, upload e timeout: i tre colli di bottiglia più comuni

Quando l’import fallisce, la causa non è sempre il database. Spesso è l’ambiente PHP che blocca il processo. I valori da controllare sono questi: upload_max_filesize, post_max_size, memory_limit e max_execution_time. Se il file supera il massimo consentito, il browser può caricarlo solo in parte o rifiutarlo del tutto.

Per capire i valori effettivi puoi usare la pagina phpinfo() se disponibile, oppure controllare la configurazione dal pannello hosting. Su alcuni ambienti condivisi i limiti non sono modificabili dal sito, quindi la soluzione non è “insistere con il retry”, ma dividere il dump o passare a un import da shell.

Se hai accesso al server, un rapido controllo può essere fatto così:

php -i | egrep 'upload_max_filesize|post_max_size|memory_limit|max_execution_time'

Se i valori sono bassi, il rimedio è aumentare i limiti in modo controllato, fare un backup della configurazione e riavviare il servizio PHP-FPM o il web server se necessario. Su stack tipici, il cambio va verificato subito con una nuova lettura di phpinfo() o del comando CLI, perché il valore atteso e quello effettivo non sempre coincidono.

Charset, collation e caratteri strani dopo il restore

Uno dei problemi più fastidiosi è l’import apparentemente corretto ma con testo corrotto, apostrofi strani o simboli sostituiti. Qui il colpevole è spesso il charset. Se il database sorgente usa utf8mb4 e quello di destinazione è impostato diversamente, il dump può essere importato ma i dati non saranno identici all’originale.

Prima del restore, controlla la collation del database e delle tabelle. Dopo il restore, verifica almeno un campo con caratteri accentati e, se presente, un campo con emoji o simboli estesi. Non basta che il sito si apra: bisogna controllare che i dati siano leggibili e coerenti.

Un esempio di verifica minimale è questo:

mysql -u root -p -e "SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';"

Se trovi incongruenze, la soluzione non è fare nuovi import a caso. Prima allinea il database di destinazione, poi esporta di nuovo se necessario. In alcuni casi conviene anche forzare il charset nella connessione di phpMyAdmin, ma va fatto con attenzione perché una correzione lato interfaccia non ripara un dump già generato male.

Import grandi: quando conviene uscire da phpMyAdmin

Se il file è grande, il problema non è solo la dimensione: è il modo in cui il browser gestisce la sessione. Un import lungo può interrompersi per timeout, reset della sessione, limiti del proxy o semplice chiusura del tab. Per questo, oltre una certa soglia, il terminale è una scelta più robusta.

Se hai un dump compresso, puoi ripristinarlo così:

gunzip < nome_database.sql.gz | mysql -u root -p nome_database

Questo approccio è più prevedibile perché non dipende dal browser. Inoltre, se qualcosa va storto, l’errore è più leggibile. La controparte è che richiede accesso shell e un minimo di attenzione alla gestione delle credenziali. Le password non vanno messe in chiaro nella cronologia: usa prompt interattivo o file di configurazione protetti, se proprio necessario.

Se stai operando in produzione, il blast radius va chiarito subito: importare sopra il database sbagliato può sovrascrivere dati live. Per questo il rollback minimo è avere sempre un export del database attuale, nominato in modo inequivocabile con data e ora, prima di toccare il target.

Strategia pratica per un restore senza sorprese

La sequenza più sicura, in un ambiente reale, è questa:

1. Fai un export del database attuale, anche se pensi di non averne bisogno.
2. Verifica dimensione, charset e presenza di routine o trigger.
3. Prepara il database di destinazione con collation corretta.
4. Importa prima un dump di test, se possibile, o una copia su ambiente non produttivo.
5. Controlla tabelle, record chiave e login applicativo.
6. Solo dopo, replica la procedura in produzione.

Questa sequenza riduce gli errori più comuni: file sbagliato, encoding sbagliato, import incompleto e restore distruttivo non previsto. Il costo è qualche minuto in più; il vantaggio è evitare ore di diagnostica dopo un import fallito.

Se usi un pannello hosting con phpMyAdmin integrato, spesso hai anche accesso a percorsi per backup automatici o snapshot del database. Quando esistono, conviene usarli come prima linea di recupero e tenere phpMyAdmin per operazioni puntuali. L’interfaccia web è utile, ma non deve essere l’unico punto di verità sullo stato dei dati.

Errori tipici e come leggerli in modo utile

Alcuni errori ricorrono spesso. “File too large” indica quasi sempre un limite di upload o post. “Maximum execution time exceeded” punta al timeout PHP. “MySQL server has gone away” può voler dire timeout lato DB, pacchetto troppo grande o connessione interrotta. “Access denied” è invece un problema di credenziali o permessi.

Il trucco è non leggere l’errore come messaggio isolato, ma come indizio di livello. Se il problema compare subito dopo il caricamento del file, è più probabile un limite web/PHP. Se compare a metà import, è più probabile un timeout o un reset della connessione. Se compare solo al primo accesso dell’app dopo il restore, il problema può essere a livello applicativo, non del database.

Per chiudere il cerchio, dopo ogni import controlla i log del servizio web e del database. Su Linux recente, i punti di partenza tipici sono i log di Apache o Nginx, i log PHP-FPM e il log MySQL/MariaDB. Anche un semplice confronto tra orario dell’errore e orario dell’import aiuta a capire se il problema nasce nel trasferimento o nell’avvio dell’applicazione.

Conclusione operativa: la differenza la fanno i controlli prima e dopo

phpMyAdmin è uno strumento pratico, non magico. Per esportare e importare bene servono tre abitudini: scegliere il formato corretto, conoscere i limiti dell’ambiente e verificare sempre il risultato. Se il dump è piccolo e il server è ben configurato, il flusso è rapido. Se il dump cresce o il contesto è delicato, conviene passare a strumenti da shell e usare phpMyAdmin solo come interfaccia di supporto.

In sintesi: esporta in modo completo, importa in un database preparato, controlla charset e limiti PHP, e non considerare finita l’operazione finché non hai validato tabelle e dati chiave. È questo che separa una procedura comoda da una procedura affidabile.