Salta al contenuto

Aggiornare MariaDB su aaPanel senza perdere i database

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.

Pubblicità

Schermata bianca con avvisi WordPress: "1 problema critico" e "2 miglioramenti raccomandati", riquadri con testo sulla

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.

Versioni di MariaDB supportate (novembre 2026)
VersioneTipoSupporto fino aNote
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 sqlite3 su Debian/Ubuntu, yum install sqlite su 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.

Interfaccia file di aaPanel con sfondo scuro, cartella /root/mariadb-upgrade/ che mostra quattro file tar.gz e.sh con nomi
  1. Fai lo snapshot del server e aspetta che sia completato.
  2. Metti in pausa le pubblicazioni programmate e, se usi il Mail Server di aaPanel, fermalo.
  3. 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 configurazione my.cnf e un archivio .tar.gz unico. Deve finire con ESITO: TUTTO OK. Se segnala anche un solo errore, fermati.
  4. Scarica l’archivio .tar.gz sul tuo computer e conservalo al sicuro: contiene le password in chiaro.
  5. Svuota l’elenco Databases di aaPanel: seleziona tutti i database, scegli Delete dal menu in basso e conferma. Da qui il sito è senza database.
  6. Disinstalla MariaDB da App Store → Installed → Uninstall. Ora aaPanel lo permette.
  7. Installa la nuova versione: cerca MySQL nell’App Store, scegli mariadb_11.4 dal menu e premi Quick install. “Compiled” compila da sorgente e può richiedere un’ora: non serve.
  8. Imposta la password di root da Databases → Root password (solo lettere e numeri) e annotala.
  9. 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.
Interfaccia aaPanel scura con sezione Databases evidenziata, elenco database con nomi e password censurate, pulsanti Delete

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

Schermata scura di aaPanel con barra di ricerca contenente "mysql", elenco di plugin e riga "mariadb11.4.4" visibile

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 (o HTTP/1.1 200). Subito dopo lo svuotamento è normale vedere miss: 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.

PHP
PHP Compatibility Checker
Controlla il tuo plugin WordPress prima di aggiornare PHP Verifica la compatibilità con PHP 8.0–8.5 Scopri eventuali problemi nel codice PHP Analizza il tuo plugin WordPress online Preparati a PHP 8.5
Verifica ora →

Scritto da

Webmaster

Mi impegno costantemente nello studio e nell'apprendimento delle ultime novità e tendenze del settore tecnologico, sia dal punto di vista teorico che pratico. Questa passione mi spinge a mettermi alla prova e a superare ogni sfida che mi viene posta, permettendomi di raggiungere i miei…

Profilo e articoli →
🔒

Contenuto riservato

Per scaricare questo file devi prima registrarti oppure accedere con il tuo account.

XWhatsAppTelegram