Si può passare da una vecchia MariaDB a una versione LTS su aaPanel con circa 10 minuti di fermo, senza ricreare a mano database, utenti e password. Lo abbiamo fatto su backdigit.com, da MariaDB 10.7.3 a 11.4.4, con due script che trovi in fondo all’articolo.
Il problema: WordPress dice che MariaDB è obsoleta
In Strumenti → Salute del sito, WordPress mostra l’avviso “La versione del server SQL è obsoleta” e raccomanda MariaDB 10.11 o superiore. Il consiglio è sensato: la 10.7 è fuori supporto da febbraio 2023 e non riceve più patch di sicurezza.
Su aaPanel, però, non c’è un pulsante “Aggiorna” per passare a un’altra serie di MariaDB. L’unica strada è disinstallare e reinstallare. E aaPanel blocca la disinstallazione finché l’elenco Databases non è vuoto, con un messaggio che invita a fare il backup e cancellare i database. Detto così sembra un lavoro lungo e rischioso: esportare ogni database, annotare utenti e password, ricrearli a mano uno per uno. Non lo è, se si automatizza.

Due scorciatoie da evitare
aaPanel compila MariaDB da sorgente in /www/server/mysql e non la gestisce con il gestore di pacchetti del sistema. Aggiungere il repository ufficiale di MariaDB e lanciare apt upgrade non aggiorna la versione di aaPanel: installa una seconda MariaDB che entra in conflitto con la prima.
Nel messaggio di blocco aaPanel suggerisce anche un comando di disinstallazione forzata, rm -rf /www/server/mysql. Non usarlo: cancella i programmi ma non i dati, che stanno in /www/server/data. La nuova installazione si ritroverebbe davanti i file della vecchia versione.
La strada pulita è: backup completo, svuotamento dell’elenco da aaPanel, disinstallazione, installazione della nuova versione, ripristino. Gli script servono a rendere backup e ripristino automatici e verificati.
Leggi anche: Come fare un backup di un sito WordPress con il plugin UpdraftPlus e come ripristinarlo (sito funzionante o corrotto)
Quale versione scegliere
Scegli una versione LTS, non l’ultima uscita: per un server WordPress la nostra scelta è la 11.4. Le versioni rolling (come la 13.0) sono supportate solo fino all’uscita della successiva, pochi mesi. Le LTS ricevono correzioni di sicurezza per anni.
| Versione | Tipo | Supporto fino a | Note |
|---|---|---|---|
| 12.3 | LTS | giugno 2029 | La più recente, stabile da maggio 2026 |
| 11.4 | LTS | maggio 2029 | La più collaudata, nostra scelta |
| 11.8 | LTS | giugno 2028 | Più nuova della 11.4 ma scade prima |
| 10.11 | LTS | febbraio 2028 | Minimo raccomandato da WordPress |
| 13.0 | Rolling | dicembre 2026 | Da evitare in produzione |
La 11.8 scade prima della 11.4 perché dalla 11.8 MariaDB ha ridotto il supporto delle LTS da 5 a 3 anni. Il salto diretto da una 10.x alla 11.4 non è un problema: passando da backup e ripristino non servono versioni intermedie.
Fonti: endoflife.date, MariaDB Foundation.
Prima di iniziare
- Accesso root via SSH al server, o il terminale di aaPanel.
- La password di root di MariaDB, da aaPanel → Databases → Root password. Se non la conosci, impostane una nuova lì: WordPress usa il proprio utente, non root.
- sqlite3 installato (
sqlite3 --version). Se manca:apt install sqlite3su Debian/Ubuntu,yum install sqlitesu CentOS/AlmaLinux. - Uno snapshot del server dal pannello del tuo provider. È la vera rete di sicurezza: se qualcosa va storto, torni esattamente a com’eri.
- Spazio su disco pari almeno alla dimensione dei database. I dump sono compressi: nel nostro caso 800 MB di dati sono diventati un archivio di 97 MB.
- Un momento di poco traffico. Le pagine in cache restano visibili ai lettori, ma admin, commenti e pagine non in cache si fermano per qualche minuto.
La procedura passo per passo
Carica i due script nella cartella /root/mariadb-upgrade/ (da aaPanel → Files o via SCP), poi segui questi passaggi senza lunghe pause tra il 3 e il 7.

- Fai lo snapshot del server e aspetta che sia completato.
- Metti in pausa le pubblicazioni programmate e, se usi il Mail Server di aaPanel, fermalo.
- Lancia il backup:
bash /root/mariadb-upgrade/mariadb-backup-1.1.sh
Chiede una sola volta la password di root e salva, in una cartella con data e ora: il dump verificato di ogni database, utenti e permessi (con l’hash delle password), l’elenco dei database di aaPanel (con le password del pannello), la configurazionemy.cnfe un archivio.tar.gzunico. Deve finire con ESITO: TUTTO OK. Se segnala anche un solo errore, fermati. - Scarica l’archivio
.tar.gzsul tuo computer e conservalo al sicuro: contiene le password in chiaro. - Svuota l’elenco Databases di aaPanel: seleziona tutti i database, scegli Delete dal menu in basso e conferma. Da qui il sito è senza database.
- Disinstalla MariaDB da App Store → Installed → Uninstall. Ora aaPanel lo permette.
- Installa la nuova versione: cerca MySQL nell’App Store, scegli
mariadb_11.4dal menu e premi Quick install. “Compiled” compila da sorgente e può richiedere un’ora: non serve. - Imposta la password di root da Databases → Root password (solo lettere e numeri) e annotala.
- Lancia il ripristino:
bash /root/mariadb-upgrade/mariadb-restore-1.1.sh
Verifica i file, mostra versione vecchia e nuova e chiede di scrivere SI. Poi ricrea gli utenti con le loro password, importa ogni database controllando il numero di tabelle e rimette i database nell’elenco di aaPanel. Deve finire con ESITO: TUTTO OK.

Nel nostro caso, dal passaggio 5 al 9 sono passati circa 10 minuti, per 4 database e 132 tabelle.

Controlli finali e risultato
Dopo il ripristino, l’admin di WordPress è risultato sensibilmente più veloce. I motivi sono due: dalla 11.0 l’ottimizzatore di MariaDB sceglie piani di esecuzione migliori sulle query pesanti (elenchi con filtri, meta, tassonomie), e l’import ricostruisce tabelle e indici senza la frammentazione accumulata negli anni. Le pagine pubbliche servite dalla cache, invece, cambiano poco.
Leggi anche: PHP, aggiornamento di sicurezza critico: cosa fare su aaPanel e sul proprio server
- Ricarica aaPanel → Databases: i database devono esserci, con la password visibile dall’occhio.
- Svuota la cache degli oggetti (Redis) e, se serve, quella delle pagine.
- Apri il sito, una pagina non in cache, wp-admin e i plugin che usano database esterni; invia una mail di prova se usi il Mail Server.
- In MariaDB → Optimization controlla
innodb_buffer_pool_size: deve essere almeno pari alla dimensione dei database, perché la reinstallazione riporta i valori predefiniti. - Riattiva pubblicazioni programmate e Mail Server.
- Tieni lo snapshot per qualche giorno, poi eliminalo insieme alla cartella
/root/mariadb-upgrade, che contiene password in chiaro.
I messaggi “Deprecated program name” che a volte compaiono sono innocui: dalla 11 il client si chiama mariadb invece di mysql, ma il vecchio nome funziona ancora.
Scarica gli script
I due script sono gratuiti e rilasciati con licenza MIT: puoi usarli, modificarli e ridistribuirli citando BACKdigit.
- mariadb-backup-1.1.sh: solo lettura, non ferma servizi e non cancella nulla. Puoi lanciarlo anche a sito online, per esempio per provarlo prima del giorno dell’aggiornamento.
- mariadb-restore-1.1.sh: si ferma se trova già uno dei database da ripristinare, così non sovrascrive niente, e chiede conferma prima di procedere.
Sono stati provati su aaPanel 8.0.7, da MariaDB 10.7.3 a 11.4.4, con WordPress e il Mail Server di aaPanel. Dovrebbero funzionare con qualunque versione di partenza e di arrivo, ma fai sempre uno snapshot prima di iniziare: li usi a tuo rischio.
Bonus: verifica e svuotamento cache in un colpo solo
Dopo il ripristino, incolla questo blocco nel terminale del server: controlla che WordPress veda il database, svuota la cache degli oggetti (Redis o Memcached) e quella delle pagine, poi mostra come risponde il sito. Cambia solo la prima riga con la cartella del tuo sito.
Leggi anche: HTTP2Shell e WordPress: come verificare se il tuo sito è esposto alla falla Brotli
Riconosce da solo i plugin di cache più diffusi: LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, WP Fastest Cache, SiteGround Optimizer, Breeze, Cache Enabler, Nginx Helper, Hummingbird e Comet Cache. Serve WP-CLI installato sul server.
SITE="/www/wwwroot/tuosito.it" # cambia solo questa riga
(
cd "$SITE" 2>/dev/null || { echo "Cartella non trovata: $SITE"; exit 1; }
[ -f wp-config.php ] || { echo "wp-config.php non trovato in $SITE"; exit 1; }
command -v wp >/dev/null || { echo "WP-CLI non installato: https://wp-cli.org"; exit 1; }
U=$(stat -c %U wp-config.php)
W() { if [ "$U" = root ] || ! command -v sudo >/dev/null; then wp --allow-root "$@"; else sudo -u "$U" -- wp "$@"; fi; }
echo "== Database"
W eval 'global $wpdb; echo "Connessione OK, server: " . $wpdb->db_server_info() . "\n";' || exit 1
echo "Sito: $(W option get home)"
echo "== Cache degli oggetti"
if [ "$(W eval 'echo wp_using_ext_object_cache() ? 1 : 0;')" = 1 ]; then
W cache flush && echo "Cache degli oggetti svuotata (Redis/Memcached)"
else
echo "Nessuna cache esterna degli oggetti"
fi
if command -v redis-cli >/dev/null; then
redis-cli ping 2>/dev/null | grep -q PONG && echo "Redis: attivo" || echo "Redis: protetto da password o non attivo (verifica dal pannello)"
fi
echo "== Cache delle pagine"
W cli has-command litespeed-purge 2>/dev/null && W litespeed-purge all
P=$(mktemp /tmp/cache-flush-XXXX.php); chmod 644 "$P"
cat > "$P" <<'PHP'
<?php
$fatti = [];
if ( has_action( 'litespeed_purge_all' ) ) { do_action( 'litespeed_purge_all' ); $fatti[] = 'LiteSpeed Cache'; }
if ( function_exists( 'rocket_clean_domain' ) ) { rocket_clean_domain(); $fatti[] = 'WP Rocket'; }
if ( function_exists( 'w3tc_flush_all' ) ) { w3tc_flush_all(); $fatti[] = 'W3 Total Cache'; }
if ( function_exists( 'wp_cache_clear_cache' ) ) { wp_cache_clear_cache(); $fatti[] = 'WP Super Cache'; }
if ( has_action( 'wpfc_clear_all_cache' ) ) { do_action( 'wpfc_clear_all_cache', true ); $fatti[] = 'WP Fastest Cache'; }
if ( function_exists( 'sg_cachepress_purge_cache' ) ) { sg_cachepress_purge_cache(); $fatti[] = 'SiteGround Optimizer'; }
if ( has_action( 'breeze_clear_all_cache' ) ) { do_action( 'breeze_clear_all_cache' ); $fatti[] = 'Breeze'; }
if ( has_action( 'cache_enabler_clear_complete_cache' ) ) { do_action( 'cache_enabler_clear_complete_cache' ); $fatti[] = 'Cache Enabler'; }
if ( has_action( 'rt_nginx_helper_purge_all' ) ) { do_action( 'rt_nginx_helper_purge_all' ); $fatti[] = 'Nginx Helper'; }
if ( has_action( 'wphb_clear_page_cache' ) ) { do_action( 'wphb_clear_page_cache' ); $fatti[] = 'Hummingbird'; }
if ( class_exists( 'comet_cache' ) && method_exists( 'comet_cache', 'clear' ) ) { comet_cache::clear(); $fatti[] = 'Comet Cache'; }
echo $fatti ? 'Cache delle pagine svuotata: ' . implode( ', ', $fatti ) . "\n"
: "Nessun plugin di cache riconosciuto: svuotala dal suo pannello\n";
PHP
W eval-file "$P"; rm -f "$P"
echo "== Risposta del sito"
curl -sI "$(W option get home)/" | grep -iE '^HTTP|x-litespeed-cache|cf-cache-status|x-cache|x-proxy-cache|x-rocket'
)
Come leggere il risultato:
- Database deve mostrare “Connessione OK” con la nuova versione di MariaDB. Se compare un errore, WordPress non riesce a collegarsi: ricontrolla utenti e password dei database.
- Cache delle pagine elenca i plugin riconosciuti e svuotati. Se il tuo non è nella lista, svuotala dal pannello del plugin.
- Risposta del sito deve iniziare con
HTTP/2 200(oHTTP/1.1 200). Subito dopo lo svuotamento è normale vederemiss: rilancia l’ultima riga dopo qualche secondo e diventeràhit.
Il blocco è racchiuso tra parentesi tonde: se qualcosa non va si ferma, ma non chiude la sessione del terminale.
Altri articoli su WP-CLI
- Plugin WordPress vulnerabili o abbandonati: come riconoscerli ed eliminarli prima che bucano il sito27 Ott
- WP-CLI: i comandi indispensabili per gestire WordPress da terminale su un VPS27 Ott
- Sito WordPress infetto: come pulirlo da terminale passo passo e non farsi reinfettare27 Ott
- Server infettato dopo PHP2Shell? I comandi da terminale per scoprirlo subito27 Ott
- WordPress piantato? Come fare il downgrade da terminale prima che sia tardi27 Ott







