Indice dei contenuti dell'articolo:
Era una mattina come tante altre nel nostro ufficio, quando il telefono squillò con insistenza. Dall’altro capo della linea, una voce concitata ci raggiunse. Era uno sviluppatore PHP che aveva deciso di gestire il proprio ambiente di produzione su una VPS in hosting presso un noto provider italiano. Aveva scelto Plesk per la sua facilità d’uso, convinto che gli avrebbe dato piena autonomia nella gestione del server senza dover dipendere da un sistemista. Tuttavia, la realtà era stata ben diversa: il gestionale della sua azienda era improvvisamente andato offline e, con esso, tutto il flusso di lavoro aziendale era paralizzato.
“Abbiamo un server con Plesk, non riusciamo a capire cosa sia successo, ma il database non si avvia!” disse con un tono che oscillava tra il panico e la disperazione.
Iniziammo a fare qualche domanda preliminare. C’era stato qualche aggiornamento recente? Qualcosa di insolito nei log? Dopo qualche minuto di conversazione, il primo indizio: “Il disco era quasi pieno… e poi, improvvisamente, tutto si è bloccato.”
Quando il Disco si Riempie: Effetti su Plesk e MariaDB
Una partizione disco satura può avere conseguenze devastanti su un server, specialmente se ospita un database MariaDB o MySQL. Se il sistema non ha più spazio disponibile per scrivere, i servizi iniziano a fallire in modo imprevedibile, i processi si bloccano e il database può corrompersi nel tentativo di completare operazioni interrotte. Questo era esattamente ciò che temevamo.
Collegandoci al server via SSH, confermammo immediatamente la gravità della situazione: la partizione principale era al 100% di utilizzo. Questo significava che MariaDB non aveva più margine per eseguire operazioni critiche, come il salvataggio dei log o la gestione del rollback delle transazioni incomplete. In questi casi, il rischio maggiore è che il motore InnoDB si blocchi in uno stato incoerente, rendendo impossibile l’avvio del database senza interventi manuali di ripristino.
L’unica azione immediata possibile era liberare spazio per ridare respiro al sistema. Dopo un’analisi rapida, individuammo e cancellammo vecchi backup lasciati in /var/lib/psa/dumps/, file di log cresciuti oltre misura e altri dati temporanei inutili. Con qualche gigabyte recuperato, provammo a riavviare MariaDB con la speranza che il problema si risolvesse spontaneamente.
Ma niente, il servizio continuava a fallire.
A quel punto, iniziammo a scavare più a fondo. Dopo aver analizzato i log di sistema e i registri di MariaDB, facemmo una scoperta allarmante: la directory /var/lib/mysql/ risultava completamente vuota e priva di qualsiasi database. Non c’era traccia dei file .ibd, .frm o .MYD che normalmente compongono un database MySQL/MariaDB.
Questa era una situazione critica: senza quei file, non c’era alcun database da recuperare. Un server MySQL senza dati è come un’auto senza motore. Ma la domanda era: dove erano finiti quei file? Era stata un’azione automatica di Plesk? MariaDB li aveva cancellati tentando un ripristino fallito?
Senza backup disponibili, il problema assumeva una gravità ancora maggiore. Per sicurezza, chiedemmo subito al cliente se fosse attivo un servizio di backup automatico o snapshot della VPS. La risposta ci fece rabbrividire: non era stato sottoscritto alcun servizio di backup o snapshotting.
Senza un backup recente, il recupero diventava una corsa contro il tempo. Suggerimmo allora di contattare il supporto del provider hosting per verificare se, per puro caso, esistesse uno snapshot non documentato della macchina. Nonostante il servizio di snapshot non fosse stato incluso nel piano, alcune aziende hosting conservano copie temporanee per uso interno, nel caso di guasti o incidenti.
L’hoster non garantiva nulla, ma promise di controllare. Nel frattempo, noi continuammo con l’analisi tecnica, determinati a scoprire dove fossero finiti i file del database e se esistesse una via di recupero.
Plesk e MariaDB: Un Problema nella Gestione
Una delle prime cose che lo sviluppatore aveva tentato di fare era accedere a Plesk per controllare lo stato del database e capire cosa fosse successo. Ma qui si trovò di fronte a un nuovo problema: Plesk stesso non era accessibile. Il motivo? Il pannello di gestione di Plesk utilizza un database chiamato psa, che risiede su MariaDB. Se il database non si avvia, anche l’interfaccia Web di Plesk diventa inutilizzabile, lasciando l’utente senza alcun punto di controllo per gestire il server.
Questa situazione può essere particolarmente frustrante per chi ha scelto Plesk proprio per la sua interfaccia user-friendly, convinto che avrebbe reso la gestione del server semplice e immediata. Tuttavia, in caso di un crash di MariaDB, tutta l’amministrazione del server si ferma, compresa la gestione degli account, dei domini e dei database stessi. Non solo: anche i servizi web e di posta elettronica potrebbero risentirne, specialmente se le configurazioni di hosting dipendono da informazioni archiviate nel database psa.
A questo punto, l’unica possibilità per intervenire è accedere via SSH con privilegi di root e risolvere il problema manualmente da riga di comando. Questo significa dover eseguire diagnosi avanzate, analizzare i log di sistema, individuare la causa del problema e applicare le dovute correzioni senza l’ausilio di un’interfaccia grafica.
Per chi non ha familiarità con la gestione avanzata di Linux, questa può essere una situazione bloccante, e tentare di risolvere il problema senza le giuste competenze può portare a ulteriori danni. Errori nell’applicazione di comandi, tentativi di reinstallazione errati o modifiche non corrette ai file di configurazione possono compromettere ancora di più il server, rendendo necessaria un’azione di disaster recovery o, nel peggiore dei casi, la reinstallazione completa della VPS.
La Scoperta Inaspettata: La Cartella mysql.repair-innodb.*.d
Dando un’occhiata alla directory /var/lib/mysql, trovammo un’anomalia preoccupante: era completamente vuota. Questo significava che, se non avessimo trovato una copia dei dati altrove, il database sarebbe stato perso irrimediabilmente. Tuttavia, sapevamo che Plesk implementa alcuni meccanismi di recupero automatico in caso di problemi con InnoDB, quindi iniziammo a cercare indizi.
Dopo qualche minuto di analisi, scoprimmo qualcosa di interessante nella cartella /var/lib/psa/dumps/: una directory chiamata mysql.repair-innodb.20250320-093623.d. Questo nome indicava chiaramente un tentativo di riparazione automatica eseguito da Plesk. Quando MariaDB rileva una corruzione grave nelle tabelle InnoDB e non riesce ad avviarsi, Plesk può tentare di spostare i dati in una directory di recupero, evitando che il database danneggiato impedisca il riavvio del servizio. Tuttavia, il processo di riparazione automatica non sempre va a buon fine, e in questo caso sembrava che fosse stato interrotto lasciando i file fermi in questa posizione.
A quel punto, la missione era chiara: recuperare manualmente il database. Spostammo l’intero contenuto della cartella mysql.repair-innodb.20250320-093623.d nuovamente in /var/lib/mysql, ripristinando la posizione originale dei file di dati. Con il cuore in gola, tentammo di riavviare MariaDB.
Il servizio partì, segno che almeno la struttura dei dati era stata riconosciuta, ma subito ci rendemmo conto che alcune tabelle erano segnalate come corrotte. Questo poteva dipendere dal fatto che lo spostamento e il tentativo di riparazione precedente non erano stati completati correttamente. Non ci facemmo prendere dal panico e passammo immediatamente allo step successivo: il controllo e la riparazione delle tabelle per ristabilire completamente l’integrità del database.
Riparazione e Ottimizzazione del Database
Lanciammo mysqlcheck --repair --all-databases, un comando fondamentale per verificare e tentare la riparazione di tutte le tabelle presenti nel database. Questo strumento, integrato in MariaDB, permette di eseguire controlli di integrità sui file di dati e correggere eventuali danni alle tabelle. L’operazione richiese diversi minuti: il server era sotto stress per l’assenza di ottimizzazioni recenti e l’accumulo di errori dovuti alla saturazione del disco.
Osservavamo con attenzione l’output del terminale, aspettando di vedere segnali positivi. Dopo qualche momento di suspense, iniziarono ad apparire i primi messaggi incoraggianti: diverse tabelle erano state riparate con successo. Alcune richiesero più tentativi, mentre per altre furono necessarie operazioni più profonde di recupero dei dati interni. Fortunatamente, nessuna delle tabelle principali risultò completamente irrecuperabile, evitando così il rischio di una perdita catastrofica di informazioni.
A quel punto, il database era di nuovo funzionante, ma non ci fermammo lì. Per garantire stabilità e performance ottimali, eseguimmo anche un’operazione di ottimizzazione con il comando:
mysqlcheck --optimize --all-databases
Questo passaggio era cruciale perché, dopo una riparazione, i file delle tabelle possono risultare frammentati e occupare più spazio del necessario, rallentando le query. L’ottimizzazione consolidò i dati, deframmentò gli indici e migliorò l’efficienza del database.
Terminata anche questa operazione, eseguimmo un controllo finale. Il servizio MariaDB era stabile, le query rispondevano senza errori e il gestionale tornò a funzionare correttamente. Dopo tre giorni di inattività, l’azienda del nostro interlocutore poteva finalmente riprendere il proprio lavoro.
Dall’altro capo della linea, sentimmo un lungo sospiro di sollievo. “Non so come ringraziarvi, pensavo di aver perso tutto!” disse con gratitudine. Noi, invece, sapevamo bene che, con la giusta esperienza e un metodo strutturato, anche le situazioni più critiche possono essere spesso risolte.
Perché Plesk Ha Spostato /var/lib/mysql in /var/lib/psa/dumps/?
Quando un database MariaDB/MySQL presenta problemi critici legati a tabelle InnoDB corrotte o a file di dati danneggiati, Plesk può attivare automaticamente un meccanismo di tentativo di riparazione d’emergenza. Questo processo viene avviato nel momento in cui il servizio MariaDB non riesce ad avviarsi correttamente a causa di errori di integrità sui file di database.
Uno degli approcci adottati da Plesk in questi scenari è lo spostamento temporaneo dell’intero contenuto della directory /var/lib/mysql/ in un’area di sicurezza, che si trova tipicamente sotto /var/lib/psa/dumps/. Qui viene creata una cartella con un nome del tipo:
/var/lib/psa/dumps/mysql.repair-innodb.YYYYMMDD-HHMMSS.d
Questa cartella ha il compito di conservare una copia dei file di database nel loro stato originale prima di tentare qualsiasi operazione di riparazione. L’idea alla base di questa procedura è evitare che MariaDB rimanga in uno stato corrotto irreversibile, consentendo all’amministratore di tentare un recupero manuale dei dati se necessario.
Quando Plesk Decide di Spostare /var/lib/mysql?
Il trasferimento dei file del database in una directory di sicurezza può verificarsi in vari scenari, tra cui:
-
Saturazione della partizione disco – Se il server esaurisce lo spazio disponibile, MariaDB potrebbe bloccarsi mentre sta scrivendo file di registro o dati, lasciando alcune tabelle InnoDB in uno stato inconsistente. Plesk potrebbe quindi tentare di spostare i file per liberare spazio e provare un avvio pulito.
-
Corruzione delle tabelle InnoDB – Se durante l’avvio MariaDB rileva tabelle danneggiate, il motore InnoDB potrebbe rifiutarsi di partire per evitare ulteriori danni. In questi casi, Plesk può intervenire spostando i dati in un’area separata per isolare il problema e tentare una riparazione.
-
Ripristino automatico fallito – In alcuni casi, Plesk potrebbe tentare di avviare MariaDB con un’opzione di recupero forzato (come
innodb_force_recovery), ma se l’operazione non riesce, può lasciare i file in/var/lib/psa/dumps/per evitare che un database danneggiato impedisca ogni successivo tentativo di recupero. -
Aggiornamenti del sistema o crash imprevisti – Durante un aggiornamento di Plesk o del motore MariaDB, se il server viene riavviato in modo non corretto o si verificano errori di compatibilità, alcuni file di database potrebbero risultare danneggiati. Plesk potrebbe allora spostare
/var/lib/mysql/per preservare lo stato dei dati prima di forzare un riavvio del servizio.
Cosa Succede se il Processo si Interrompe?
Se il tentativo di riparazione automatica viene interrotto o non va a buon fine, il database non viene ripristinato e la directory principale /var/lib/mysql/ resta vuota, generando un grave problema: MariaDB non trova più i suoi file di dati e non può avviarsi.
A questo punto, Plesk non mostra alcun avviso chiaro all’amministratore sul motivo per cui il database risulta non funzionante. L’unico modo per scoprirlo è accedere via SSH e ispezionare manualmente le cartelle.
Se si trova una cartella come /var/lib/psa/dumps/mysql.repair-innodb.*.d, è molto probabile che Plesk abbia tentato un recupero automatico ma non sia riuscito a completarlo. In questi casi, è necessario spostare manualmente i file dalla cartella di recupero alla directory originale (/var/lib/mysql/) e procedere con un ripristino manuale del database.
Plesk ci prova, aiuta, ma non Basta
Sebbene Plesk tenti di gestire autonomamente situazioni di emergenza, il suo meccanismo di riparazione non è infallibile e può lasciare il server in una condizione critica se l’operazione non viene completata correttamente.
A meno che non si abbia una profonda conoscenza della gestione di MariaDB da riga di comando, recuperare un database spostato automaticamente da Plesk può diventare un’operazione complessa e rischiosa.
Per questo motivo, quando si gestisce un server con Plesk, è fondamentale:
- Monitorare lo spazio su disco per prevenire saturazioni improvvise.
- Effettuare backup regolari dei database, indipendentemente dalle funzioni automatiche di Plesk.
- Avere accesso SSH con privilegi root per poter intervenire manualmente in caso di problemi gravi.
Per maggiori dettagli sulle procedure di riparazione automatica di Plesk, puoi consultare la documentazione ufficiale:
La Morale: Autonomia vs. Competenza Sistemistica
Plesk è probabilmente il migliore dei pannelli web per la gestione di hosting e server, ma affidarsi esclusivamente a un’interfaccia grafica non è sempre una scelta vincente. Il problema principale di Plesk non è tanto la sua funzionalità, quanto la falsa sicurezza che può dare a chi lo utilizza senza competenze sistemistiche avanzate.
Molti utenti si affidano a Plesk convinti che l’interfaccia grafica sia sufficiente per garantire una gestione completa del server, senza mai dover mettere mano alla riga di comando. Tuttavia, quando si verificano problemi critici come il crash di MariaDB, l’intera infrastruttura basata su Plesk si blocca, rendendo impossibile qualsiasi intervento senza accesso SSH e competenze Linux avanzate.
Un altro aspetto spesso trascurato è che Plesk, di default, non offre protezioni adeguate contro scenari catastrofici, come la saturazione del disco o la corruzione dei database. Se un utente non configura manualmente snapshot regolari, backup automatici e monitoraggio proattivo delle risorse, rischia di trovarsi in situazioni di emergenza senza una via d’uscita.
E qui sta il punto cruciale: chi utilizza Plesk non è quasi mai un sistemista. Il target tipico di questo strumento sono sviluppatori, agenzie, e-commerce manager o freelance, che hanno bisogno di gestire siti web e applicazioni senza doversi occupare dell’infrastruttura sottostante. Questo porta inevitabilmente a un circolo vizioso: l’utente si affida a Plesk pensando di non dover mai affrontare problemi complessi, ma quando questi si presentano, non ha gli strumenti né le conoscenze per risolverli.
Quando un server si blocca, quando un database scompare, quando Plesk stesso diventa inaccessibile, non è più questione di cliccare pulsanti o seguire guide online. Servono competenze reali, servono strumenti da riga di comando, servono anni di esperienza per sapere come affrontare il problema senza peggiorare la situazione.
La soluzione più prudente? Affidarsi a sistemisti Linux professionisti, con esperienza decennale, capaci di prevenire e gestire problemi critici prima che diventino disastri. Un’interfaccia grafica può facilitare la gestione ordinaria, ma quando tutto va storto, è l’esperienza di un vero esperto a fare la differenza tra il recupero e la perdita totale dei dati.
