Repara una base de datos SQLite dañada — sin subirla

¿La base de datos no abre? Recupérala ahora

1. Suelta el archivo .db / .sqlite
2. La recuperación ocurre en local
3. Descarga una base de datos nueva y abrible

Para recuperar una base de datos SQLite dañada no «arreglas» el archivo roto en su sitio — lees todo lo que todavía es decodificable y lo escribes en una base de datos totalmente nueva, exactamente como funciona el propio comando .recover de SQLite. Eso se ejecuta aquí mismo, en tu navegador: suelta el archivo arriba, el diagnóstico muestra qué está dañado y el motor de recuperación reconstruye el esquema y vuelve a insertar cada fila que puede leer. No se instala nada y la base de datos nunca se sube.

Los errores que esto cubre

El clásico SQLITE_CORRUPT. Algo en la estructura de páginas del archivo es incoherente — una página de árbol B dañada, un puntero de celda incorrecto, un recuento de páginas que no concuerda con el tamaño del archivo. El motor se detiene en el primer problema que encuentra, pero las páginas que nunca alcanzó suelen estar bien, y un escaneo en bruto puede extraer las filas directamente de ellas.

SQLite dice esto cuando el número mágico de 16 bytes de la cabecera («SQLite format 3\0») es incorrecto. Dos causas muy distintas: los bytes de la cabecera se dañaron (las páginas que hay detrás suelen estar intactas y son recuperables), o el archivo es realmente otra cosa — o una base de datos cifrada (SQLCipher/SEE), que se lee como ruido de alta entropía y no se puede recuperar sin la clave. El diagnóstico distingue entre las dos.

Síntomas derivados del mismo daño de páginas subyacente. Si volver a abrir el archivo produce el mismo fallo, las soluciones in situ se han agotado y una reconstrucción a partir de las páginas supervivientes es el siguiente paso.

Cómo se rompe un archivo SQLite: páginas y punteros

Una base de datos SQLite es un array plano de páginas de tamaño fijo (normalmente 4 KB cada una). La página 1 contiene la cabecera y el esquema; cada tabla e índice es un árbol B cuyas páginas interiores apuntan hacia abajo a las páginas hoja que contienen tus filas reales. El software lee la cabecera, encuentra el esquema y luego sigue esos punteros hasta los datos.

Los punteros son el punto débil. Una sola escritura interrumpida, un sector defectuoso, una sincronización que se detuvo a medias o un bit invertido en una página interior y la cadena de punteros se rompe — SQLite se topa con una incoherencia y declara toda la imagen malformada, aunque tus filas sigan intactas en sus páginas hoja. Es la misma historia que el índice ausente de un vídeo o el directorio central roto de un ZIP: se rompió el mapa, no los datos.

Por eso funciona la recuperación: las páginas hoja llevan registros autodescriptivos, así que el motor puede recorrer el archivo página por página, decodificar las filas que encuentra y reconstruir los árboles B desde cero a su alrededor. Las filas que los punteros no pueden alcanzar se localizan con un barrido en bruto; las filas que no coinciden con ninguna tabla conocida van a una tabla lost_and_found en lugar de tirarse.

Si tienes un archivo -wal, tráelo

Las bases de datos en modo WAL preparan los cambios recientes en un archivo hermano <nombre>-wal hasta que se consolidan en la base de datos principal. Tras un bloqueo, tus datos confirmados más recientes pueden vivir solo ahí. Suelta primero el .db principal y luego añade el archivo -wal en la ranura opcional para archivos auxiliares: sus marcos confirmados se superponen antes del escaneo, de modo que la base de datos recuperada refleja la última transacción confirmada en lugar del último checkpoint. Es opcional — la recuperación funciona bien solo con el archivo principal — pero si tienes el archivo auxiliar, a menudo es donde están las filas más recientes.

Por qué el «sin subida» importa en las bases de datos

Piensa en lo que contiene de verdad una base de datos: cuentas de usuario, mensajes, historial de ubicaciones, el estado entero de una aplicación. Es el único archivo que menos querrías ver en el servidor de otra persona «solo para repararlo». Las herramientas de recuperación basadas en subida lo copian de tu equipo y lo procesan en una infraestructura que no puedes inspeccionar. La recuperación en el navegador elimina ese paso por completo — el archivo se lee desde tu disco, se reconstruye en tu pestaña y no existe ninguna copia en ningún otro sitio. Para el trabajo forense (DFIR) sobre pruebas, eso además mantiene intacta la cadena de custodia: el artefacto nunca sale de la estación de trabajo. Puedes verificarlo en la pestaña Red mientras se ejecuta la recuperación.

Qué puede y qué no puede recuperar

El informe de recuperación enumera lo que salió de cada tabla, señala las filas extraídas por el escaneo en bruto o descartadas por indescifrables, y una recuperación fallida nunca se cobra.