Ripara un database SQLite danneggiato — senza caricarlo

Il database non si apre? Recuperalo adesso

1. Trascina il file .db / .sqlite
2. Il recupero avviene in locale
3. Scarica un database nuovo e apribile

Per recuperare un database SQLite malformato non si «ripara» il file rotto sul posto — si legge tutto ciò che è ancora decodificabile e lo si scrive in un database completamente nuovo, esattamente come funziona il comando .recover di SQLite. Tutto questo avviene proprio qui, nel tuo browser: trascina il file qui sopra, la diagnosi mostra cosa è danneggiato e il motore di recupero ricostruisce lo schema e reinserisce ogni riga che riesce a leggere. Non si installa nulla e il database non viene mai caricato.

Gli errori che questo copre

Il classico SQLITE_CORRUPT. Qualcosa nella struttura a pagine del file è incoerente — una pagina B-tree danneggiata, un puntatore di cella errato, un conteggio di pagine che non concorda con la dimensione del file. Il motore si ferma al primo problema che incontra, ma le pagine che non ha mai raggiunto di solito sono integre, e una scansione grezza può estrarne le righe direttamente.

SQLite lo dice quando il numero magico di 16 byte dell'intestazione («SQLite format 3\0») è errato. Due cause molto diverse: i byte dell'intestazione sono stati danneggiati (le pagine che stanno dietro sono spesso intatte e recuperabili), oppure il file è davvero qualcos'altro — o un database cifrato (SQLCipher/SEE), che si legge come rumore ad alta entropia e non può essere recuperato senza la chiave. La diagnosi distingue i due casi.

Sintomi derivati dallo stesso danno alle pagine sottostante. Se riaprire il file produce lo stesso errore, le soluzioni sul posto si sono esaurite e una ricostruzione a partire dalle pagine sopravvissute è il passo successivo.

Come si rompe un file SQLite: pagine e puntatori

Un database SQLite è un array piatto di pagine di dimensione fissa (di solito 4 KB ciascuna). La pagina 1 contiene l'intestazione e lo schema; ogni tabella e ogni indice è unB-tree le cui pagine interne puntano verso il basso alle pagine foglia che contengono le tue righe vere e proprie. Il software legge l'intestazione, trova lo schema e poi segue quei puntatori fino ai dati.

I puntatori sono il punto debole. Basta una singola scrittura interrotta, un settore difettoso, una sincronizzazione fermatasi a metà o un bit invertito in una pagina interna e la catena di puntatori si spezza — SQLite si imbatte in un'incoerenza e dichiara malformata l'intera immagine, anche se le tue righe sono ancora lì, intatte, nelle loro pagine foglia. È la stessa storia dell'indice mancante di un video o della directory centrale rotta di uno ZIP: si è rotta la mappa, non i dati.

Ecco perché il recupero funziona: le pagine foglia contengono record autodescrittivi, quindi il motore può percorrere il file pagina per pagina, decodificare le righe che trova e ricostruire i B-tree da zero attorno ad esse. Le righe che i puntatori non riescono a raggiungere vengono individuate con una scansione grezza; le righe che non corrispondono a nessuna tabella conosciuta finiscono in una tabellalost_and_found invece di essere buttate via.

Se hai un file -wal, aggiungilo

I database in modalità WAL preparano le modifiche recenti in un file gemello <nome>-wal finché non vengono consolidate nel database principale. Dopo un crash, i tuoi dati confermati più recenti possono trovarsi solo lì. Trascina prima il .db principale, poi aggiungi il file -wal nell'apposito spazio per i file ausiliari: i suoi frame confermati vengono sovrapposti prima della scansione, così il database recuperato riflette l'ultima transazione confermata anziché l'ultimo checkpoint. È opzionale — il recupero funziona benissimo anche solo con il file principale — ma se hai il file ausiliario, spesso è lì che si trovano le righe più recenti.

Perché il «niente caricamenti» conta per i database

Pensa a cosa contiene davvero un database: account utente, messaggi, cronologia delle posizioni, l'intero stato di un'applicazione. È l'ultimo file che vorresti veder finire sul server di qualcun altro «solo per ripararlo». Gli strumenti di recupero basati sul caricamento lo copiano dalla tua macchina e lo elaborano su un'infrastruttura che non puoi ispezionare. Il recupero nel browser elimina del tutto quel passaggio — il file viene letto dal tuo disco, ricostruito nella tua scheda, e non esiste alcuna copia da nessun'altra parte. Per il lavoro forense (DFIR) sulle prove, questo mantiene intatta anche la catena di custodia: il reperto non lascia mai la postazione di lavoro. Puoi verificarlo nella scheda Rete mentre il recupero è in corso.

Cosa può e cosa non può recuperare

Il report di recupero elenca ciò che è uscito da ogni tabella, segnala le righe estratte dalla scansione grezza o scartate perché non decodificabili, e un recupero fallito non viene mai addebitato.