Logseq and Continuous Backups

tl;dr:
I’ve switched my personal notes over to Logseq, even though I’ve heard complaints it can lose data. Here’s a continuous-backup wrapper script you can apply to any program that loses your work.

Why Logseq?

I found the backlinks and transclusions¹  compelling. Linking and embeds/transclusions are not only for pages, these can be applied to individual “blocks”. Frequently I want the same information to be accessible from multiple places, and Logseq has a good UI for this. An interlinked network of text-blocks just makes sense to me.

I know that Roam Research and some others have similar features, but Logseq is fully FOSS.² 

Why Not Logseq?

These notes are fairly important and contain my own personal documentation for how I manage pieces of the infrastructure that keeps me functioning. Meanwhile, I have seen various complaints across the internet about Logseq losing data or behaving in confusing ways. The safest thing to do would be to use a simple text editor that is nearly incapable of losing important information.

Using Unpredictable Software Anyway

Of course, using a simple text editor, I’d miss out on the features I want.

One nice thing about Logseq is that it stores data in a bunch of markdown files, so edits are completely transparent to a casual observer.³ 

Given this highly-legible backing store, it’s almost completely trivial to mitigate any concern about data loss.⁴ 

Automatic Snapshots

At first I’d considered taking snapshots of my notes every minute or so, but this would needlessly churn the disk. Then I remembered that change detection is easy with Inotify. Inotify is one of my favorite tools - you can use it to track filesystem events and notify a user process.⁵ 

If you want to see what it does, you can install inotify-tools (almost certainly available in most Linux distros) and run something like this:

inotifywait -m -r -e modify,create,delete,moved_to $SOME_DIRECTORY
#this filters for write events, but you can monitor read-only events too!

That will show you all changes to any files or folders within the given directory, streaming to your terminal.

Monitoring changes in this way, it’s easy to take a snapshot in response.

Why not git?

Logseq has some built-in automatic git-based versioning. Semantically, this seems wrong to me (but that’s only because of my philosophy about notes). I see notes as evolving but not really “versioned” in the same way that source code is. I see git commits as, ideally, meaningful and capturing an atomic intention. Automating commits separates them from any user intention. Of course, git doesn’t care, and it would work fine.

Another reason to build a wrapper is to avoid trusting Logseq to make its own backups. I haven’t read the code, I don’t know what it’s doing in there. Meanwhile, I know exactly what my wrapper does.

Wrapper Script

Here’s the script I have wrapped Logseq with.

It uses a tiny standalone restic repository, then takes snapshots on launch, on quit, and whenever changes have been made (but never more than one within 30 seconds).

You can wrap any program with this script. You’d still have to remember to save frequently, but, 30 seconds after it hits the disk, even the worst-behaved program in the world can’t nuke your work.⁶