Suggested restoration procedure to restore any page, asset, etc, using git on the CLI

I don’t use Logseq Sync, and I just used this workflow to restore some lost content on a page.

TLDR/BLUF: rsync a copy of your graph’s directory on the filesystem to a temporary location where we can poke around without consequences, find the commit you want your file/page/asset to be at using git, check it out and view it, and then check it out in your real graph’s directory.

This procedure is probably written up somewhere, but I wanted to share it in case it isn’t, and see if anyone has any optimizations or improvements to it.

It’s good for one file/page/asset at a time, which is what I describe here, but you could easily omit the path to the file from the git commands, and restore the entire graph to a previous point in its history; just be careful, and always test it out first.



To do this, your desired original state of the page needs to be committed in version control for your graph.

  1. in Logseq, go to Settings → Version Control → Enable git auto commit, and turn it on
    in your Logseq graph
  2. Adjust the autocommit period to your liking (I use 5 minutes, but might go lower again, after today)

Find the correct version of the file

Work in a copy of your graph, initially

For a change that happened while you had autocommit enabled, you can do the following.

First, work with a copy of our Logseq graph’s directory (a git repository, now that we’ve enabled autocommit) on the filesystem, in order to prevent the risk of restoring files and then having those autocommitted before we’ve reviewed them (we do eventually want this) or making other blunders using git incorrectly. For a graph mygraph on the filesystem:

rsync -avP <path_to_mygraph> /tmp/restore-my-logseq-graph
# we'll leave out the bit about trailing slashes in Logseq for now

This is a full fledged git repository, with all your history.

Find the commit before the one that introduced the undesirable change

To do this, for a given file myfile (a page, say), use git log with diffs, and follow changes only to that file:

cd /tmp/restore-my-logseq-graph/mygraph
git log --patch --follow --patch -- <path_to_myfile>

Find the commit that has the last desirable change, i.e., a commit that is before undesirable things started happening. You may want to search for “how view git diff” if you’re unfamiliar with the diff syntax.

Copy the commit hash.

Checkout the file at this commit

Run, while still in the temporary restored graph directory,

git checkout <commit_hash_you_copied> -- <path_to_myfile>

Inspect the file in a Markdown viewer

I use ReText, (clicking “Preview” once the file is open) but you can use anything, including opening the file in your favorite editor and making sure the raw Markdown is present as you desire it:

retext <path_to_myfile> # click "Preview" when it opens
vim <path_to_myfile>  # look at raw Markdown or use a plugin to render
# etc

Consider opening the copied directory as a new graph in Logseq

If you really wanted to see it how Logseq renders it, you could create a new graph out of your rsync’d graph location; you could even keep it somewhere more permanent on the filesystem, rather than in /tmp, and repeat this whole process any time you want to restore something (starting with rsync, to update it).

Restore the file in your original Logseq graph

If all looks good in the file in your temporary restored graph directory, you’re ready to restore it in your original Logseq graph directory

cd <path_to_mygraph>
git checkout <commit_hash_you_copied> -- <path_to_myfile>

Wait the autocommit interval, and this restoration change will also now be committed and in
your history. You can view it:

git log --patch


Congrats, you just restored a file and saved yourself hours of work. Let me know if you have any ideas to improve a process for backup if you don’t have Logseq Sync.