Rescuing your Chrome history

dankblog! 2026-05-25, 2201 EDT, at the danktower

has it really been over a year since i blogged here? sheesh.

for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant User Data/ subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database in memory and on disk, meaning your history becomes null ("what?" you ask. "how can it corrupt the database on disk if the disk is full?" that's a great question, one to which i'd like to know the answer. obviously it's editing something in-place, or reserved some space, but it definitely happens.) visited sites can't be seen, and new loads aren't recorded. this seems a pretty substantial bug, but i guess no PM in mountain view gives a shit. so it goes. i have no insight into the mysteries of Chrome development planning.

if you close chrome and start it again following this corruption, the database (History in the user folder) is helpfully recreated from scratch, aka permanently lost. this is not usually what you want.

if you notice the problem has occurred (you'll typically get a "you need to free up space!" message in Chrome), take the following steps:

1. change to the relevant subdirectory of User Data/, usually Default
2. run sqlite3 History .recover > /tmp/chrome-history.sql
3. close running Chrome processes
4. clean up necessary space, you disgusting hoarder
5. run sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql
6. run mv /tmp/chrome-history History
7. run rm /tmp/chrome-history.sql
8. start Chrome

you ought have the vast majority of your history. obviously you can and should replace the hardcoded filenames with mktemp invocations. you ought write them to a directory that is not world-readable, unless you don't mind people being able to read your browser history.

previously: "GT2025" 2025-04-17