IntactFile

Réparez une base de données SQLite corrompue — sans la téléverser

« Database disk image is malformed » ne signifie presque jamais que vos données sont perdues. Cela veut dire qu'une seule page ou un seul pointeur s'est rompu et que SQLite refuse le fichier entier. La récupération balaie les pages et reconstruit une base de données propre à partir de ce qui a survécu.

Votre base de données ne quitte jamais votre appareil — la récupération s'exécute dans votre navigateur. 0 octet téléversé.

Your data is the big block — usually intact. What breaks is the small index. Repair rebuilds it.

Drop a file here or browseTap to choose a file

ZIP · Office · PDF · video · JPG · PNG · RAR/7z · SQLite — repaired right here in your browser. Nothing is uploaded

0 bytes uploadedFree: 3 repairs/day — up to 500 MB video, 100 MB docs & archives, 50 MB photos. Free download. Single repair €5.90. No account required.

La base de données refuse de s'ouvrir ? Récupérez-la maintenant

  1. Déposez le fichier .db / .sqlite
  2. La récupération s'exécute en local
  3. Téléchargez une base de données neuve et ouvrable

Pour récupérer une base de données SQLite malformée, on ne « répare » pas le fichier cassé sur place — on lit tout ce qui est encore décodable et on l'écrit dans une base de données entièrement neuve, exactement comme fonctionne la propre commande .recover de SQLite. Cela s'exécute ici même, dans votre navigateur : déposez le fichier ci-dessus, le diagnostic montre ce qui est endommagé, et le moteur de récupération reconstruit le schéma et réinsère chaque ligne qu'il parvient à lire. Rien n'est installé, et la base de données n'est jamais téléversée.

Les erreurs que cela couvre

Error: database disk image is malformed (11)

Le classique SQLITE_CORRUPT. Quelque chose dans la structure en pages du fichier est incohérent — une page d'arbre B corrompue, un pointeur de cellule erroné, un nombre de pages qui ne concorde pas avec la taille du fichier. Le moteur s'arrête au premier problème rencontré, mais les pages qu'il n'a jamais atteintes sont généralement intactes, et un balayage brut peut en extraire les lignes directement.

file is not a database

SQLite affiche cela lorsque le nombre magique de 16 octets de l'en-tête (« SQLite format 3\0 ») est incorrect. Deux causes très différentes : les octets de l'en-tête ont été endommagés (les pages qui se trouvent derrière sont souvent intactes et récupérables), ou le fichier est réellement autre chose — ou encore une base de données chiffrée (SQLCipher/SEE), qui se lit comme un bruit à haute entropie et ne peut pas être récupérée sans la clé. Le diagnostic fait la différence entre les deux.

database or disk is full / malformed database schema

Des symptômes dérivés du même dommage de pages sous-jacent. Si rouvrir le fichier produit le même échec, les corrections sur place sont épuisées et une reconstruction à partir des pages survivantes est l'étape suivante.

Comment un fichier SQLite se casse : pages et pointeurs

Une base de données SQLite est un tableau plat de pagesde taille fixe (généralement 4 Ko chacune). La page 1 contient l'en-tête et le schéma ; chaque table et chaque index est un arbre Bdont les pages internes pointent vers le bas, vers les pages feuilles qui contiennent vos lignes réelles. Le logiciel lit l'en-tête, trouve le schéma, puis suit ces pointeurs jusqu'aux données.

Les pointeurs sont le point faible. Une seule écriture interrompue, un secteur défectueux, une synchronisation qui s'est arrêtée à mi-chemin, ou un bit inversé dans une page interne, et la chaîne de pointeurs se rompt — SQLite rencontre une incohérence et déclare toute l'image malformée, alors même que vos lignes reposent toujours, intactes, dans leurs pages feuilles. C'est la même histoire que l'index manquant d'une vidéo ou le répertoire central cassé d'un ZIP : c'est la carte qui s'est cassée, pas les données.

C'est pourquoi la récupération fonctionne : les pages feuilles portent des enregistrements autodescriptifs, si bien que le moteur peut parcourir le fichier page par page, décoder les lignes qu'il trouve et reconstruire les arbres B de zéro autour d'elles. Les lignes que les pointeurs ne peuvent pas atteindre sont retrouvées par un balayage brut ; les lignes qui ne correspondent à aucune table connue vont dans une tablelost_and_found au lieu d'être jetées.

Si vous avez un fichier -wal, apportez-le

Les bases de données en mode WAL préparent les changements récents dans un fichier voisin <name>-wal jusqu'à ce qu'ils soient consolidés (checkpoint) dans la base de données principale. Après un plantage, vos données validées les plus récentes peuvent ne vivre que là. Déposez d'abord le .db principal, puis ajoutez le fichier-wal dans l'emplacement facultatif pour fichier auxiliaire : ses trames validées sont superposées avant le balayage, de sorte que la base de données récupérée reflète la dernière transaction validée plutôt que le dernier checkpoint. C'est facultatif — la récupération fonctionne très bien avec le seul fichier principal — mais si vous avez ce fichier auxiliaire, c'est souvent là que se trouvent les lignes les plus fraîches.

Pourquoi le « sans téléversement » compte pour les bases de données

Pensez à ce que contient réellement une base de données : comptes d'utilisateurs, messages, historique de localisation, l'état entier d'une application. C'est le fichier qu'on voudrait le moins voir traîner sur le serveur de quelqu'un d'autre « juste pour le réparer ». Les outils de récupération fondés sur le téléversement le copient depuis votre machine et le traitent sur une infrastructure que vous ne pouvez pas inspecter. La récupération dans le navigateur supprime cette étape entièrement — le fichier est lu depuis votre disque, reconstruit dans votre onglet, et aucune copie n'existe ailleurs. Pour le travail forensique (DFIR) sur des preuves, cela préserve aussi la chaîne de possession intacte : l'artefact ne quitte jamais le poste de travail. Vous pouvez le vérifier dans l'onglet Réseau pendant que la récupération s'exécute.

Ce que cela peut et ne peut pas récupérer

Peut récupérer

  • « Database disk image is malformed » dû à une page endommagée ou à un pointeur d'arbre B
  • Des champs d'en-tête corrompus (taille ou nombre de pages incorrect) avec des pages intactes derrière eux
  • Fichiers tronqués : chaque ligne d'une page survivante est extraite
  • Les lignes des pages que la chaîne de pointeurs ne peut plus atteindre, via un balayage de pages brut
  • Les changements non consolidés d'un fichier auxiliaire -wal fourni

Ne peut pas récupérer

  • Les lignes physiquement écrasées ou coupées à la fin — ces données n'existent plus
  • Les bases de données chiffrées (SQLCipher/SEE) sans la clé — les pages sont du texte chiffré
  • Les affinités exactes des colonnes : les valeurs reviennent selon leur classe de stockage sur disque
  • Une garantie d'exactitude — les données récupérées sont toujours suspectes ; vérifiez-les
  • Les fichiers de 0 octet : c'est d'abord un problème de récupération de données du périphérique de stockage

Le rapport de récupération énumère ce qui est sorti de chaque table, signale les lignes extraites par le balayage brut ou abandonnées car indécodables, et une récupération échouée n'est jamais facturée.

Questions fréquentes

Que signifie « database disk image is malformed » ?

C'est l'erreur SQLITE_CORRUPT de SQLite (code de résultat 11) : le moteur a suivi un pointeur à l'intérieur du fichier et a trouvé quelque chose qui n'est pas une page d'arbre B valide — une page mise à zéro, un décalage de cellule erroné, une page qui pointe au-delà de la fin du fichier. Cela ne signifie pas que toutes les lignes ont disparu. En pratique, une seule page endommagée ou un champ d'en-tête erroné fait tomber le fichier entier, alors que le reste de vos tables reste bien là, intact. La récupération parcourt les pages directement, reconstruit le schéma et réinsère chaque ligne qu'elle peut encore décoder dans une base de données entièrement neuve — la même stratégie que la propre commande .recover de SQLite.

Peut-on vraiment récupérer une base de données SQLite corrompue dans le navigateur ?

Oui. Déposez le fichier .db (ou .sqlite/.sqlite3) ci-dessus. Le scanner de pages est en TypeScript pur et s'exécute entièrement dans votre onglet : il lit chaque page en local, reconstruit le schéma, parcourt l'arbre B de chaque table et se rabat sur un balayage de pages brut, sans pointeurs, pour tout ce que l'arbre B ne peut pas atteindre. Les lignes qui ne peuvent être rattachées à une table connue sont placées dans une table lost_and_found plutôt que jetées. Le résultat est un fichier de base de données neuf et ouvrable que vous téléchargez. Aucun concurrent ne propose la récupération de SQLite côté navigateur — la plupart vous obligent à téléverser le fichier sur un serveur.

Qu'est-ce que le fichier -wal, et en ai-je besoin ?

SQLite en mode WAL (write-ahead logging, journalisation par écriture anticipée) conserve les changements récents dans un fichier voisin nommé -wal jusqu'à ce qu'ils soient consolidés (checkpoint) dans le .db principal. Si votre application a planté, les données les plus récentes peuvent ne vivre que dans ce fichier -wal. Si vous l'avez, ajoutez-le dans l'emplacement facultatif pour fichier auxiliaire après avoir déposé la base de données : ses trames validées sont superposées avant le balayage, de sorte que la récupération reflète la dernière transaction validée. Pas de -wal ? La récupération s'exécute quand même sur le fichier principal — vous ne verrez simplement pas les changements qui n'ont jamais été consolidés.

Est-il prudent de faire passer ma base de données par un outil de réparation en ligne ?

Une base de données est souvent la pire chose à confier à un serveur que vous ne contrôlez pas : elle peut renfermer chaque enregistrement d'utilisateur, chaque message ou chaque identifiant que votre application a jamais stockés. Les outils fondés sur le téléversement copient ce fichier sur leur infrastructure, selon des conditions de conservation que vous n'avez pas écrites. Ici, rien n'est téléversé — le fichier est lu depuis votre disque et reconstruit dans votre navigateur, et vous pouvez surveiller l'onglet Réseau pour confirmer que 0 octet est transmis.

Quelles applications stockent leurs données dans SQLite, pour que je sache si cela me concerne ?

Presque tout. Les applications iOS et Android, les navigateurs (historique, cookies, stockage des extensions), Signal et d'autres messageries, les applications de notes, les clients de messagerie, les catalogues Lightroom et d'innombrables outils de bureau conservent tous leurs données dans des bases de données SQLite — souvent avec une extension .db, .sqlite, .sqlite3 ou propre à l'application. Si un outil indique que sa base de données est corrompue, « malformed » ou « not a database », cette page est faite pour lui. Les analystes DFIR tombent sur les mêmes fichiers en extrayant des artefacts d'une image disque.

Pourquoi toutes les lignes ne peuvent-elles pas revenir ?

L'honnêteté d'abord : les données récupérées d'une base de données corrompue sont toujours suspectes — la documentation même de SQLite le dit, et vous devriez les vérifier par rapport à une source fiable avant de vous y fier. Tout ce qui a été physiquement écrasé ou coupé de la fin du fichier a disparu ; aucun outil ne peut l'inventer. Les valeurs reviennent selon leur classe de stockage sur disque, si bien que le type d'une colonne peut changer. Et comme le balayage lit les pages de la liste libre (freelist) et les pages non compactées, des lignes précédemment supprimées peuvent refaire surface. Le rapport de récupération vous dit exactement ce qui s'est passé, table par table.

En lien : le tableur refuse de s'ouvrir — réparer des fichiers Excel · le document refuse de s'ouvrir — réparer des fichiers PDF · l'archive refuse de s'extraire — réparer des fichiers ZIP ·vérifier la promesse du zéro téléversement