I don’t use Logseq Sync, and I just used this workflow to restore some lost content on a page.
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.
- in Logseq, go to Settings → Version Control → Enable git auto commit, and turn it on
in your Logseq graph
- Adjust the autocommit period to your liking (I use 5 minutes, but might go lower again, after today)
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.
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.
Run, while still in the temporary restored graph directory,
git checkout <commit_hash_you_copied> -- <path_to_myfile>
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
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).
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.