La base de datos "History" de Chrome está malformada

Tu historial no se guarda en un formato propietario — es una base de datos SQLite que reside en el directorio de perfil de Chrome: en Windows %LOCALAPPDATA%\Google\Chrome\User Data\Default\History, en macOS ~/Library/Application Support/Google/Chrome/Default/History y en Linux ~/.config/google-chrome/Default/History (Chromium usa ~/.config/chromium/…, Edge …/Microsoft/Edge/…, Brave …/BraveSoftware/Brave-Browser/…). El archivo se llama History sin extensión, y por eso mucha gente no cae en que puede abrirlo en cualquier herramienta SQLite — cambia el nombre de una copia a History.db y DB Browser for SQLite lo leerá al instante.

Dentro están las tablas que componen tu registro de navegación. urls guarda una fila por cada página que has visitado — sus columnas son id, url, title, visit_count, typed_count, last_visit_time y hidden. visits es la línea de tiempo: cada fila tiene una clave foránea url que apunta de vuelta a urls.id, un visit_time, un from_visit que señala la visita anterior (así se reconstruyen las cadenas de atrás/adelante) y una máscara de bits transition cuyo byte bajo es el tipo principal (LINK = 0, TYPED = 1, AUTO_BOOKMARK = 2, RELOAD = 8). Junto a ellas están keyword_search_terms, downloads y downloads_url_chains, segments/segment_usage (que alimentan los accesos directos de la Nueva pestaña) y una pequeña tabla meta con las filas version y last_compatible_version que le indican a Chrome qué esquema está mirando.

Un detalle hace tropezar a todo el que exporta el historial: las marcas de tiempo no son tiempo Unix. last_visit_time y visit_time se guardan como microsegundos desde el 1601-01-01 00:00:00 UTC (la época de Chrome/WebKit). Para leer una como fecha normal, divides entre 1.000.000 y restas 11.644.473.600 segundos. La recuperación conserva los enteros tal cual están en el disco, así que las fechas sobreviven a la reconstrucción — solo las conviertes después.

Una base de datos SQLite es una matriz plana de páginas de tamaño fijo — Chrome usa el valor por defecto de 4096 bytes. La página 1 lleva la cabecera y el esquema; cada tabla, incluidas urls y visits, es un árbol-b cuyas páginas interiores apuntan hacia páginas hoja que contienen tus filas reales. Chrome ejecuta la base de datos History en modo WAL (write-ahead logging), así que junto a ella verás normalmente archivos hermanos llamados History-wal y History-shm; las versiones más antiguas y algunos perfiles dejan en su lugar un diario de reversión llamado History-journal.

Esa maquinaria de archivos hermanos es justo por donde se cuela el daño. Si la máquina pierde corriente, el disco se llena o Chrome se cierra a mitad de un checkpoint, un frame del WAL puede escribirse solo a medias de vuelta en el archivo principal — una única página interior queda con un puntero de celda inconsistente o con un recuento de páginas que no cuadra con el tamaño del archivo. SQLite sigue ese puntero, encuentra algo que no es una página de árbol-b válida y se detiene con Error: database disk image is malformed (11) — código de resultado SQLITE_CORRUPT. Ejecuta PRAGMA integrity_check y verás los detalles: líneas como *** in database main ***, Page 214: btreeInitPage() returns error code 11, row 1803 missing from index urls_url_index o wrong # of entries in index visits_url_index.

Lo importante: el motor se detiene en la primera inconsistencia, pero las páginas que nunca llegó a alcanzar suelen estar perfectas, y tus filas siguen intactas en sus páginas hoja. Es la misma historia que el índice moov ausente de un vídeo o el directorio central roto de un ZIP — se rompió el mapa, no los datos. Por eso una reconstrucción a nivel de página recupera tanto donde abrir el archivo con normalidad no recupera nada.

Un archivo History malformado no se arregla en el sitio — se lee todo lo que aún se puede descodificar y se escribe en una base de datos nueva, exactamente como funciona el propio comando .recover de SQLite. El escáner lee cada página localmente, reconstruye el esquema a partir de las definiciones que sobreviven y luego recorre el árbol-b de cada tabla y descodifica los registros autodescriptivos de sus páginas hoja. Las filas que la cadena de punteros ya no puede alcanzar se encuentran con un barrido bruto de páginas, y todo lo que se descodifica pero no coincide con ninguna tabla conocida se escribe en una tabla lost_and_found en lugar de desecharse.

En la práctica, eso devuelve lo esencial de tu historial: la tabla urls (direcciones, títulos de página, visit_count, last_visit_time), la línea de tiempo visits con sus tipos de transition y sus cadenas from_visit, y — donde sus páginas estén intactas — keyword_search_terms, downloads y los datos de segments. Si todavía tienes el archivo hermano History-wal, añádelo en la ranura opcional después de soltar el archivo principal: sus frames confirmados se superponen antes del escaneo, de modo que la reconstrucción refleja la última transacción confirmada en vez del último checkpoint — a menudo las últimas horas de navegación. La salida es un archivo SQLite nuevo y abrible que descargas; cámbiale el nombre de vuelta a History, déjalo en la carpeta del perfil con Chrome cerrado y tu historial reaparece, o simplemente consúltalo en cualquier visor SQLite.

La recuperación devuelve lo que está físicamente presente; no puede inventar lo que se sobrescribió. Las filas que quedaron truncadas al final del archivo, o cuyas páginas se reutilizaron tras un borrado, han desaparecido — ninguna herramienta puede traerlas de vuelta. La mayor pérdida con Chrome en concreto es el tiempo: cuando Chrome abre un archivo History que considera malformado, con frecuencia lo borra y crea uno nuevo y vacío en el acto, así que el original dañado se sobrescribe en el sitio. Si eso ya ocurrió, cierra Chrome de inmediato y recupera desde una copia de seguridad o una copia antigua de History/History-wal — el archivo vacío que lo reemplazó no tiene nada dentro que encontrar.

Dos advertencias menores, dichas con claridad. Los valores recuperados vuelven como su clase de almacenamiento en disco, así que puede que no se reaplique la afinidad declarada de una columna — las marcas de tiempo siguen siendo los enteros de microsegundos correctos, solo las conviertes tú. Y los datos recuperados de una base de datos dañada siempre son sospechosos: lo dice la propia documentación de SQLite, y como un barrido bruto también lee páginas de la lista libre, una URL borrada antes puede reaparecer de vez en cuando. El informe de recuperación indica tabla por tabla qué salió y qué se extrajo con el barrido bruto. Nada de esto necesita un servidor: el archivo History — que es un mapa de todos los sitios en los que has estado — se lee desde tu disco y se reconstruye en tu pestaña, y puedes observar la pestaña Red para confirmar que salen 0 bytes.