Reparar un places.sqlite de Firefox dañado (marcadores e historial)

Todo el sistema de marcadores e historial de Firefox vive en un solo archivo. moz_places guarda una fila por cada URL que has visitado o marcado alguna vez: su url, su title, rev_host (el host invertido, para agrupar dominios rápidamente), visit_count, last_visit_date, un guid, un url_hash y frecency, una puntuación exclusiva de Firefox que combina frecuencia y recencia (frequency + recency) y ordena las sugerencias de la barra de direcciones. Cada visita concreta es una fila en moz_historyvisits, cuyo place_id apunta de vuelta a moz_places.id. Tu árbol de marcadores es moz_bookmarks: cada fila lleva un parent, una position, un title, un guid y una clave foránea fk hacia moz_places. El árbol cuelga de carpetas raíz fijas con guids permanentes de 12 caracteres: root________, menu________ (Menú de marcadores), toolbar_____ (Barra de marcadores), unfiled_____ (Otros marcadores), mobile______ y tags________. A su alrededor están moz_origins, moz_keywords, las tablas de anotaciones moz_anno_attributes/moz_annos/moz_items_annos, moz_inputhistory y moz_meta. Los favicons no están aquí: desde Firefox 55 viven en un favicons.sqlite aparte, en el mismo perfil.

Físicamente, el archivo es un array plano de páginas de tamaño fijo. Firefox crea places.sqlite con un tamaño de página de 32 KiB (PRAGMA page_size = 32768, compilado como SQLITE_DEFAULT_PAGE_SIZE) —ocho veces el valor por defecto de 4 KiB de SQLite— y lo ejecuta en modo WAL, así que verás dos archivos hermanos junto a él: places.sqlite-wal (el registro de escritura anticipada) y places.sqlite-shm (un índice en memoria compartida). 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.

Esos punteros son el punto débil. Una escritura interrumpida, un fallo a mitad de un checkpoint, un disco lleno, un sector defectuoso o un byte volteado en una página interior de 32 KiB bastan: SQLite sigue el puntero, encuentra algo que no es una página válida y declara malformada toda la imagen, mientras tus filas siguen intactas en las páginas hoja a las que nunca llegó. Lo que se rompió es el mapa, no los datos.

Firefox comprueba places.sqlite al arrancar. Si la apertura choca con SQLITE_CORRUPT o falla una comprobación de integridad, el servicio Places trata el archivo como inservible y hace algo drástico sin preguntar: renombra places.sqlite a places.sqlite.corrupt en la carpeta del perfil, crea un places.sqlite nuevo y vacío, y después restaura tus marcadores desde el archivo con fecha más reciente de la carpeta bookmarkbackups: bookmarks-YYYY-MM-DD_<count>_<hash>.jsonlz4, comprimido con el mozLz4 de Mozilla (una cabecera mágica de 8 bytes mozLz40\0, luego un tamaño descomprimido de 4 bytes en little-endian y después un bloque LZ4; no es LZ4 estándar, así que las herramientas normales no lo abren).

Aquí está la trampa que lleva a la gente a buscar una solución: solo se hace copia de seguridad de los marcadores. El historial, las puntuaciones de frecency, las palabras clave y el historial de entrada nunca se escriben en esos archivos .jsonlz4, así que un reinicio reconstruye en silencio tu árbol de marcadores y descarta todo lo demás. Tus marcadores vuelven con buen aspecto; meses o años de historial simplemente desaparecen de la base de datos activa.

Las cadenas de error que verás en realidad, y qué significan: database disk image is malformed es SQLITE_CORRUPT (código de resultado 11): una página dañada, un desplazamiento de celda incorrecto o un recuento de páginas que no concuerda con el tamaño del archivo. file is not a database es SQLITE_NOTADB (código 26): la cabecera mágica de 16 bytes SQLite format 3\000 está dañada, aunque las páginas que hay detrás suelen estar intactas. Y The bookmarks and history system will not be functional because one of Firefox's files is in use by another application es otra cosa: es un bloqueo (SQLITE_BUSY), normalmente un segundo proceso de Firefox o un antivirus reteniendo el archivo, no una corrupción. Como el renombrado ocurre de forma automática, para cuando notas la barra vacía los datos buenos ya están en places.sqlite.corrupt y el places.sqlite activo está en blanco.

En lugar de parchear el archivo roto sobre la marcha, la herramienta lee sus páginas de 32 KiB directamente, reconstruye el esquema a partir de la página 1, recorre el árbol B de cada tabla y recurre a un escaneo de páginas en bruto sin punteros para las filas que los punteros rotos ya no pueden alcanzar: la misma estrategia que el propio comando .recover de SQLite. Los registros que no se pueden atribuir a una tabla conocida se colocan en una tabla lost_and_found en lugar de descartarse, así que una fila estropeada de moz_places o moz_bookmarks se conserva en vez de perderse. Si todavía tienes el archivo hermano places.sqlite-wal, añádelo en la ranura opcional: en modo WAL, las visitas y los marcadores más recientes pueden vivir solo en ese registro hasta que se hace el checkpoint, y sus tramas confirmadas se superponen antes del escaneo. El resultado es un places.sqlite nuevo que sí abre y que descargas: cópialo de vuelta al perfil con Firefox cerrado, o ábrelo en modo solo lectura para exportar marcadores e historial.

Usa el archivo places.sqlite.corrupt si Firefox ya ha reiniciado tu perfil: ahí es donde sigue tu historial. Para encontrarlo, abre about:profiles y pulsa "Abrir directorio" (directorio raíz) del perfil en uso, o ve directamente a %APPDATA%\Mozilla\Firefox\Profiles\<nombre> en Windows, ~/Library/Application Support/Firefox/Profiles/<nombre> en macOS o ~/.mozilla/firefox/<nombre> en Linux. Copia el archivo fuera con Firefox completamente cerrado para que nada lo tenga bloqueado.

Por qué esto no debe subirse: places.sqlite es, literalmente, un registro completo de cada página que has visitado. Es el único archivo que menos querrías ver copiado en el servidor de una empresa de reparación "solo para arreglarlo", bajo condiciones de retención que nunca leíste. Aquí se lee desde tu disco y se reconstruye en la pestaña del navegador: puedes abrir el panel de Red (Network) y comprobar que 0 bytes de la base de datos salen nunca de tu equipo.