Come recuperare un database MySQL dopo l’eliminazione di file o di una partizione in Ubuntu: RAID 6 e LUKS2
-
Autore:
Anton Kryvoruchko
-
Editore:
Mykhailo Miroshnichenko
L’eliminazione di file o di un’intera partizione del disco in Ubuntu può causare una perdita di dati critica, soprattutto se sul server è in esecuzione un database MySQL. La situazione diventa molto più complessa quando il sistema di archiviazione è basato su un array RAID 6 e i dati sono ulteriormente protetti con crittografia LUKS2. In tali condizioni, gli strumenti standard di recupero non sempre producono il risultato atteso e azioni imprudenti possono distruggere definitivamente le informazioni. In questo articolo esamineremo i possibili scenari di perdita dei dati, le specificità del lavoro con RAID 6 e LUKS2 e il processo di recupero di un database MySQL dopo l’eliminazione accidentale di file o di una partizione del disco.
- Preparazione dell’ambiente di test e del database MySQL
- Collegamento delle unità per l’analisi
- Come recuperare un database MySQL eliminato da RAID 6 + LUKS2
- PASSO 1. Rilevamento automatico delle partizioni RAID 6 e LUKS
- PASSO 2. Sblocco e recupero dei file eliminati
- PASSO 3. Ripristino del database da un dump SQL
- PASSO 4. Ripristino del database dai file fisici di MySQL
- PASSO 5. Ripristino della struttura delle tabelle dai file ibd
- PASSO 6. Collegamento dei file ibd recuperati
- Conclusione
- Domande frequenti
- Commenti
I file del database MySQL e i relativi backup su un server Linux possono diventare inaccessibili per vari motivi: eliminazione accidentale di file, formattazione o eliminazione di una partizione, danneggiamento del file system, guasto dell’array RAID, guasto del disco o guasto del controller RAID. La situazione diventa ancora più complessa se i dati sono archiviati in una partizione LUKS2 crittografata.
Hetman RAID Recovery aiuta a ricostruire le strutture degli array RAID, individuare le partizioni perse, sbloccare LUKS2 se la password è disponibile e recuperare file di database e dump SQL.
Mostreremo il programma su un computer con Windows. Tuttavia, Hetman RAID Recovery è disponibile anche per Linux e macOS.
Come recuperare un database MySQL eliminato da RAID 6 + LUKS2 (Ubuntu)
Preparazione dell’ambiente di test e del database MySQL
Per i test abbiamo utilizzato un server Dell PowerEdge R710 con controller PERC H700.
| Parametro | Specifiche |
|---|---|
| Modello del server | Dell PowerEdge R710 |
| Fattore di forma | Rack 2U |
| Processore | Fino a 2 × Intel Xeon serie 5500/5600 |
| RAM | DDR3 ECC, fino a 288 GB (18 slot) |
| Controller RAID | Dell PERC H700 |
| Tipo di RAID | RAID hardware |
| Livelli RAID supportati | RAID 0, 1, 5, 6, 10, 50, 60 |
| Configurazione dell’array | RAID 6 |
| Interfaccia delle unità | SAS/SATA, fino a 6 Gbit/s |
| Numero di vani per unità | Fino a 6 × 3,5″ o 8 × 2,5″ a seconda della configurazione |
| Cache del controller RAID | 512 MB o 1 GB (a seconda del modello) |
| Protezione della cache | BBU — protezione della cache con batteria |
| Sistema operativo | Ubuntu Server |
| Crittografia dei dati | LUKS2 (a livello Linux, non sul controller RAID) |
| Sistema di gestione del database | MySQL |
| Tolleranza ai guasti di RAID 6 | Consente il guasto simultaneo di fino a due dischi |
| Strumenti diagnostici | Dell OpenManage, MegaCLI, StorCLI (se compatibili) |
Per fornire al sistema operativo accesso diretto a ciascun disco fisico, sul controller sono stati creati sei array RAID 0 a disco singolo, uno per ogni disco. Ubuntu Server 24.04 è stato installato su uno di essi, mentre gli altri quattro sono stati combinati in un array software MD RAID 6 tramite Cockpit.
Sull’array sono state create una tabella delle partizioni GPT e tre partizioni, con ext4 come file system e crittografia LUKS2 selezionata per ciascuna di esse.
La directory mysql-data è stata collocata sulla terza partizione e conteneva i dati del database di test company_db, i file di sistema e i log di MySQL. È stata utilizzata la versione 8.0.46 di MySQL.
Il database stesso conteneva le tabelle customers, products e orders, oltre a una vista, una stored procedure e una funzione.
Il backup del database è stato creato in MySQL Workbench come dump SQL e salvato nella directory mysql-backups.
Prima del test, le directory mysql-data e mysql-backups sono state copiate dalla terza partizione alla seconda. Quindi la seconda partizione è stata eliminata tramite Cockpit e i file del database e il dump SQL sono stati eliminati dalla terza partizione usando Shift + Delete, bypassando il Cestino. In questo modo sono stati preparati due scenari: il recupero di file da una partizione eliminata e il recupero di file eliminati da una partizione conservata.
Collegamento delle unità per l’analisi
Nel nostro caso, i dischi appartenenti a RAID 6 sono stati collegati a un computer Windows tramite una docking station USB e Hetman RAID Recovery è stato avviato per l’analisi.
Oltre a lavorare con dischi fisici, il programma supporta l’analisi di immagini disco complete byte per byte. Tali immagini possono essere create direttamente in Hetman RAID Recovery usando la funzione Salva disco e archiviate su un altro disco integro.
Ciò è particolarmente utile se il disco è instabile, presenta settori danneggiati o genera errori di lettura. La creazione di un’immagine preserva i dati leggibili e consente di analizzare in seguito la copia, riducendo il numero di accessi ripetuti al disco problematico.
Se i dischi rimangono sul server Linux e sono leggibili, possono essere analizzati in remoto. Per farlo, connettiti al server tramite SSH in Hetman RAID Recovery e ottieni accesso ai suoi dispositivi a blocchi.
Come recuperare un database MySQL eliminato da RAID 6 + LUKS2
PASSO 1. Rilevamento automatico delle partizioni RAID 6 e LUKS
Subito dopo l’avvio, Hetman RAID Recovery ha rilevato automaticamente la configurazione MD RAID 6 e ne ha ricostruito la struttura per l’analisi.
Il pannello destro visualizza i parametri principali dell’array: tipo e stato di RAID, ordine e dimensione dei blocchi, nonché l’elenco dei dischi partecipanti con la relativa sequenza, gli offset e le dimensioni.
Sull’array assemblato, il programma ha rilevato tre partizioni, inclusa la seconda precedentemente eliminata, e ha identificato la crittografia LUKS su tutte e tre. Prima dell’inserimento della password, i relativi file system non vengono visualizzati: le partizioni devono essere sbloccate per l’analisi successiva.
La seconda partizione viene mostrata nell’interfaccia come spazio non allocato contrassegnato LUKS. Ciò significa che il programma ha riconosciuto i metadati del contenitore crittografato nella posizione della partizione eliminata.
PASSO 2. Sblocco e recupero dei file eliminati
Per avviare l’analisi, fare doppio clic sulla partizione richiesta. Poiché è crittografata con LUKS2, il programma chiederà di inserire una password o di specificare un file chiave. Inserire la password e fare clic su Sblocca.
Per prima cosa, selezionare Scansione rapida. Attendere il completamento della scansione, dopodiché il programma aprirà la struttura delle cartelle trovate. Nel nostro test, la scansione rapida ha trovato i file richiesti sulla partizione eliminata.
Se nel vostro caso i dati richiesti non vengono trovati, tornate alla selezione del tipo di analisi ed eseguite Analisi completa, specificando il file system EXT2/3/4.
Esaminate i risultati della scansione. Nel nostro caso, il programma ha visualizzato il dump SQL backup1.sql, la directory company_db e i file delle tabelle MySQL con estensione .ibd. Il contenuto del dump SQL può essere controllato nella finestra di anteprima.
Selezionate i file e le cartelle che desiderate recuperare, quindi fate clic su Recupera. Scegliete un metodo di salvataggio, specificate un altro disco fisico e mantenete abilitata l’opzione per ripristinare la struttura delle directory.
Non salvate i file trovati sullo stesso disco da cui vengono recuperati, per evitare di sovrascrivere altri dati persi.
PASSO 3. Ripristino del database da un dump SQL
Il modo più semplice per ripristinare il database è utilizzare il dump SQL recuperato. Esso contiene i comandi per creare la struttura del database e ripristinare i dati allo stato in cui si trovavano al momento della creazione del backup. Se sono state selezionate le opzioni di esportazione appropriate, il dump includerà anche viste, procedure e funzioni.
Avviate MySQL Workbench e connettetevi al server MySQL. Aprite il menu Server — Data Import, selezionate Import from Self-Contained File e specificate il file SQL recuperato.
Se è stata persa l’intera directory mysql-data con i file di sistema di MySQL, è necessario prima ripristinare il funzionamento del server o preparare una nuova istanza MySQL. Solo dopo sarà possibile importare il dump tramite Workbench.
Selezionate lo schema di destinazione oppure create un nuovo database company_db, quindi fate clic su Start Import. Attendere il completamento dell’operazione e controllare il registro per eventuali errori.
Aggiornate l’elenco degli schemi. Il database dovrebbe ora contenere le tabelle customers, products e orders. Apritele e verificate i record.
PASSO 4. Ripristino del database dai file fisici di MySQL
Se non è disponibile un dump SQL adatto, ma Hetman RAID Recovery è riuscito a recuperare la directory del database con i file delle tabelle, è possibile tentare un ripristino fisico.
Nel nostro caso, la directory company_db conservava i file customers.ibd, products.ibd e orders.ibd. Ciascuno di essi contiene i dati e gli indici della rispettiva tabella InnoDB.
La semplice copia di questi file nella directory MySQL non è sufficiente. Il nuovo server non dispone ancora delle definizioni delle tabelle corrispondenti nel dizionario dei dati. Pertanto, il recupero consiste in due fasi: prima è necessario ricreare la struttura della tabella, quindi collegare ad essa i file .ibd recuperati.
Per il recupero, preparate un server funzionante con la stessa versione di MySQL. Connettetevi ad esso tramite Workbench e create un database vuoto.
Se è conservato lo script SQL originale con la struttura, eseguite i comandi CREATE TABLE in esso contenuti. Le tabelle devono corrispondere esattamente a quelle originali, inclusi i tipi di colonna, le chiavi, gli indici, il collation e il formato di riga. Non è necessario eseguire i comandi di inserimento dei dati: in questa fase le tabelle devono rimanere vuote.
PASSO 5. Ripristino della struttura delle tabelle dai file ibd
Se lo script SQL originale non è disponibile, è possibile tentare di recuperare la struttura della tabella dai file .ibd. In MySQL 8.0, essi contengono SDI — i metadati del dizionario dei dati. Per leggerli viene utilizzato l’utilità ibd2sdi.
Eseguite il programma per ciascun file recuperato e salvate i risultati in formato JSON. Nel nostro caso, abbiamo ottenuto i metadati da customers.ibd, products.ibd e orders.ibd, quindi abbiamo usato jq per esaminare la definizione della tabella customers.
I metadati possono includere il nome della tabella, la versione di MySQL, il motore di archiviazione, il collation e i parametri del tablespace. Contengono anche le definizioni delle colonne. Le informazioni sulle chiavi primarie e univoche, sugli indici secondari e sulle relazioni con altre tabelle sono memorizzate separatamente.
Il JSON risultante può essere analizzato manualmente in un editor di testo. In base ai parametri rilevati, script e convertitori speciali possono generare automaticamente comandi preliminari CREATE TABLE. Per un numero elevato di tabelle, ciò accelera notevolmente il recupero della struttura.
PASSO 6. Collegamento dei file ibd recuperati
In Workbench, disabilitate temporaneamente i controlli delle chiavi esterne ed eseguite il comando ALTER TABLE … DISCARD TABLESPACE per ciascuna tabella creata. In questo modo viene scollegato il tablespace vuoto creato e la tabella viene preparata per l’aggancio del file recuperato.
Dopodiché, copiate i corrispondenti file .ibd nella directory del database sul server preparato. Dopo la copia, non dimenticate di assegnare ai file il proprietario mysql e di impostare le autorizzazioni di accesso necessarie.
Tornate in Workbench ed eseguite ALTER TABLE … IMPORT TABLESPACE per ciascuna tabella. Gli avvisi relativi all’assenza dei file .cfg non sono critici: MySQL continuerà l’importazione senza la convalida automatica della struttura. MySQL registrerà i tablespace recuperati e collegherà i dati e gli indici alle definizioni delle tabelle create in precedenza.
Dopo un’importazione riuscita, riattivate i controlli delle chiavi esterne. Aggiornate l’elenco degli schemi e verificate il numero e il contenuto dei record usando query SELECT.
I file .ibd consentono di ripristinare le tabelle, i relativi dati e gli indici. Tuttavia, viste, procedure e funzioni non sono memorizzate come file separati nella directory company_db. Se non sono incluse nel dump SQL, questi oggetti devono essere ricreati manualmente.
Dopo aver verificato il database ripristinato, si consiglia di creare un nuovo backup in formato SQL dump.
Conclusione
Utilizzando Hetman RAID Recovery, è stato possibile ricostruire automaticamente la struttura di Linux MD RAID 6 e rilevare e sbloccare i contenitori LUKS2 utilizzando la password nota. Una scansione rapida ha trovato i file richiesti sia dopo la loro eliminazione sia dopo l’eliminazione di un’intera partizione.
Il dump SQL recuperato può essere importato tramite MySQL Workbench, ripristinando la struttura del database e i dati allo stato in cui si trovavano al momento della creazione del backup. Se non è disponibile un dump adatto, è possibile recuperare le singole tabelle InnoDB dai file .ibd, ricreandone prima la struttura.
