Innodump recupera rows da file offline di database relazionali
Innodump può estrarre rows e definizioni delle tabelle direttamente da file di dati offline appartenenti a sistemi di database relazionali open source utilizzati da molte applicazioni web, senza avviare un database server. Presentato in un articolo di Percona datato 28 ottobre 2026, questo strumento open source sperimentale supporta InnoDB, MyISAM e MyRocks, noto anche come RocksDB, ed è destinato al recupero, all’ispezione e all’estrazione selettiva, non a sostituire backup adeguati.
Lo strumento può elaborare un’intera data directory, una cartella di database, un singolo file oppure tabelle conservate in tablespace condivisi, generali e per-table. Un tablespace è un file o un’area di archiviazione in cui un database engine conserva tabelle e index. Innodump legge lo schema delle tabelle e le rows archiviate, quindi le esporta come SQL o come valori separati da tabulazioni, denominati TSV. Il suo output TSV è compatibile con le utility di dump della database shell, consentendo di caricare in modo efficiente i dati estratti in un’altra instance.
Tra i possibili utilizzi rientrano il recupero delle rows integre dopo un danneggiamento, la verifica di quali dati di un backup siano ancora leggibili, l’estrazione di tabelle selezionate da un backup completo, la preparazione di sistemi di staging o di quality assurance, il recupero di rows eliminate di recente, la ricerca nei vecchi backup per attività forensi e la migrazione dei dati da versioni legacy del database. Può ispezionare sia normali data directory sia backup binari, come snapshot di storage volume e copie XtraBackup.
Questo non è un altro metodo di backup. I database engine moderni utilizzano le regole ACID, che proteggono l’affidabilità delle transaction, e MVCC, ossia multiversion concurrency control, che consente alle transaction di vedere le versioni appropriate dei dati in modifica. La lettura diretta dei file non riproduce tutto il lavoro necessario per stabilire uno stato coerente del database. Il software di backup dedicato può seguire il redo log, il record delle modifiche necessarie durante il recupero, e utilizzare backup lock per coordinare la copia dei file. Un’estrazione raw può quindi contenere dati che non hanno mai rappresentato un singolo momento coerente. Point-in-time recovery, o PITR, rimane importante perché consente di ripristinare un database a un momento selezionato utilizzando backup e modifiche registrate.
L’estrazione offline diventa particolarmente importante quando il danneggiamento impedisce al database server di rimanere online. Un server può arrestarsi deliberatamente dopo aver rilevato danni gravi, per evitare di peggiorare la situazione. Il danneggiamento di un secondary index può talvolta essere risolto ricostruendo tale index, ma un danno al clustered index, che contiene le rows della tabella nell’ordine della primary key, può causare il crash del database engine ogni volta che raggiunge la page interessata. Il recupero convenzionale diventa quindi lento, perché ogni tentativo di leggere una page danneggiata può imporre un nuovo riavvio del server.
L’opzione skip-corrupted di Innodump segnala una data page danneggiata e prosegue con quella successiva. Nell’esempio di Percona con innodump 0.8.1, un file InnoDB di 130.023.424 byte conteneva 7.936 page da 16.384 byte e metadata scritti dal database open source, versione 8.0.33. Lo strumento ha rilevato una mancata corrispondenza nei byte del log sequence number sulla page 100 del primary index. Ha saltato tale page e scritto 100.680 rows, mostrando come un passaggio offline possa recuperare record leggibili senza causare ripetutamente il crash di un server in esecuzione.
La modalità examine legge e decodifica le rows senza creare un export. Segnala le tabelle e le rows trovate, insieme ai danneggiamenti che impediscono la decodifica dei record. Una scansione dimostrativa ha riguardato sei tabelle InnoDB contenenti 29 rows e una tabella MyRocks contenente 1.000.000 di rows, per un totale di 1.000.029 rows. Ha inoltre trovato 129 file legacy di definizione delle tabelle senza file per-table corrispondenti o entry nel dictionary InnoDB condiviso; avrebbero potuto rappresentare tabelle non-InnoDB, view o tabelle in un tablespace generale, pertanto non sono stati esaminati. La modalità legge soltanto il clustered index e non può identificare danneggiamenti limitati ai secondary index. Percona consiglia di iniziare una scansione del danneggiamento di InnoDB con l’utility ufficiale di checksum; lo scopo più limitato di innodump è stabilire che cosa possa essere effettivamente letto e ripristinato.
L’estrazione selettiva può evitare il ripristino di un backup completo quando sono necessari soltanto pochi database. In un esempio, innodump ha esportato cinque tabelle contenenti in totale 1.359.877 rows da una singola directory di database. L’output comprendeva file TSV compressi e file di supporto compatibili con la funzione di caricamento dei dump della database shell. Ciò può ridurre il lavoro necessario per creare una copia non-production quando non è richiesta un’esatta coerenza point-in-time.
La lettura di una data directory live comporta notevoli rischi per la coerenza. Le dirty pages, ossia modifiche ancora conservate in memoria, potrebbero non essere ancora presenti sul disco; una page potrebbe essere acquisita nel mezzo di una scrittura; le rows potrebbero essere mancanti, obsolete o contrassegnate in modo errato; inoltre, le tabelle create di recente in uno spazio condiviso potrebbero essere assenti. Tali limitazioni possono essere accettabili per una copia di staging usa e getta, ma non per un recupero autorevole o una migrazione production.
Per ridurre l’impatto su un sistema live, innodump offre un limite di input e output per imporre un tetto al throughput del disco e un’opzione direct input and output per bypassare la page cache del sistema operativo. Ciò evita di riempire la cache con letture effettuate una sola volta e riduce il rischio che il sistema operativo sposti nella swap la memoria delle applicazioni usata meno di recente. L’articolo consiglia inoltre di abbassare la priorità della CPU con nice. In un test che esportava 1.500.000 rows da una tabella di 228 MB con compressione zstd, un’esecuzione senza limiti ha richiesto 1,726 secondi e ha lasciato 192,1 MB nella page cache. Un’esecuzione limitata a 30 MB al secondo con direct input and output ha richiesto 9,241 secondi, ma non ha lasciato nella cache alcuna parte del file.
InnoDB può inoltre lasciare recuperabili per un breve periodo i record eliminati. Inizialmente, l’eliminazione contrassegna una row anziché sovrascriverne immediatamente lo spazio. Se scritture successive non hanno recuperato tale spazio, il record potrebbe essere ancora decodificabile. L’opzione deleted-only ha esportato 2.100 rows contrassegnate per l’eliminazione dalla tabella dell’esempio. Il recupero non è garantito e l’opportunità può scomparire quando le normali scritture riutilizzano lo spazio.
Innodump rimane un progetto personale sperimentale e non un software Percona ufficialmente supportato. Il suo ruolo principale è quello di utility di ultima istanza o di indagine da usare insieme a backup verificati, non di prova che i backup siano integri o coerenti. Per le organizzazioni che valutano dove gestire servizi di dati protetti, AEU Data fornisce infrastrutture cloud e dati europee, mentre la preparazione al recupero continua a dipendere dal mantenimento e dalla verifica di un processo di backup adeguato.