Remote Git Repository Support for Backup

[EduardSchwarzkopf]

Hey, I'm currently in the rabbit-hole of getting the right wiki for my homelab and LeafWiki seems to hit the sweet spot for me!

It is just that I'm not sure if there is already a solution, that I don't see, or the feature is missing: an optional way to auto-commit page saves and push them to a remote git repository for backup purposes. I've seen this on Otterwiki, but they also have this as an experimental feature: Repository Management docs

I've run LeafWiki locally, but could not find any option for this, so my question is, if there are plans for a feature like this.

My Idea as a workaround would be to have a cronjob, doing a git commit each night, so have some sort of daily backups of the data dir, but maybe someone else has a better solution for this.

Thanks for the great project!

[perber]

Hi @EduardSchwarzkopf,

Thanks for your kind words and that you are using LeafWiki.
You are right: LeafWiki currently does not have built-in remote Git backup support.

For your use case, I would distinguish this from full repository management. I don’t think LeafWiki should necessarily expose Git as part of the normal editing workflow, require users to write commit messages, or turn Git into the primary content workflow. That can get complex quickly and would move LeafWiki closer to a Git-backed editor.

I think a good fit could be to have an optional backup-style integration:

• commit the LeafWiki data directory automatically
• use generated commit messages
• push to a configured remote repository
• show the last backup status
• maybe provide a manual “backup now” action later

So more “remote Git backup” than “Git workflow inside the editor”.

For now, your cronjob workaround is probably the safest approach. Since LeafWiki stores its data on disk, regularly committing and pushing the data directory should work well as an external backup strategy. I would recommend testing a restore once, so you know exactly what is covered in your setup.

I’ll keep this issue open and track interest in this. A first step may also be documenting the cronjob-based backup approach before deciding whether built-in support should be added.

[perber]

I currently use VM snapshots and push the LeafWiki content directory to a separate Git repository.
The VM snapshots cover the full instance, while the Git repository gives me a portable backup of the Markdown content.

@Hugo-Galley @Tak-MK How are you handling backups at the moment?

[EduardSchwarzkopf]

I will think about the cronjob and provide detailed instructions on how I solved it. Will update soon.

[EduardSchwarzkopf]

Hi @perber,
I went ahead and tried the cronjob. Here's the script I'm using:

#!/bin/bash
set -e
cd /opt/leafwiki_data/root
TIMESTAMP=$(date +"%Y-%m-%d_%H-%M-%S")
git add .
if ! git diff --cached --quiet; then
    git commit -m "Wiki backup ${TIMESTAMP}"
    git push origin main
fi

With a daily cronjob at 22:00:

0 22 * * * bash /path/to/backup_and_push.sh >> /var/log/wiki-backup.log 2>&1

And you can see the result in my demo repo: https://github.com/EduardSchwarzkopf/demo-wiki
This is fine, but it's a bit more environment setup than I'd like.
You need git installed on the host, an SSH key wired up, the script deployed somewhere, and the cron scheduled. Plus, there is no visibility into whether the last backup actually succeeded without checking the log file manually.

---

I'd like to implement this if you're open to a PR. Here's the rough overview of what I have in mind:

• Auto-commit + push on save: debounced, so rapid edits get batched into one commit and immediately pushed to the configured remote after a quiet period (default 5 min?). Without a remote configured the feature does nothing, so it only makes sense with a remote set up.
• Configurable remote: --git-backup-remote, --git-backup-branch (default: main), and --git-backup-ssh-key / --git-backup-ssh-key-path for auth
• Admin status panel: last commit/push time, last error, and a "Push now" button
  Before I start: does this direction work for you, or are there constraints I should know about first?

[perber]

Hi @EduardSchwarzkopf,

Thanks for testing the cronjob approach and for offering to work on this.

Yes, this direction sounds good to me.

A few constraints from my side:

• Use generated commit messages only.
• Prefer integrating through a Git library instead of requiring the git binary, if practical.
• Back up only the relevant LeafWiki data directories for now: root and assets.
• Exclude temporary atomic-write files like .tmp-*.
• Keep status visibility simple: last successful backup, last error, and maybe a manual “Push now” action.

I’m not fully sure yet whether pushing after each save is the right trigger. A debounced push-after-save could work, but a scheduled backup job may be simpler and more predictable. Maybe we should start with a scheduled backup interval plus “Push now”, and add debounced-on-save later if needed.

We may also need to think about how to handle SQLite data and LeafWiki’s own system revisions later, but I would consider that out of scope for the first version.

So yes, I’m open to a PR if the first version stays small and focused.

[Tak-MK]

So far because of work I'm using a way-too-overkill k8s set up with rook-ceph volumes and k8up as backup service to a TrueNAS with Garage, and let's say I don't feel too secure with them yet 🫠 I'd rather have a simpler "push-to-git" complete backup. I've used wikijs in the past and had something similar in case you want to check.
Thanks! 😄

[Hugo-Galley]

I currently use VM snapshots and push the LeafWiki content directory to a separate Git repository.
The VM snapshots cover the full instance, while the Git repository gives me a portable backup of the Markdown content.

@Hugo-Galley @Tak-MK How are you handling backups at the moment?

I’m probably a bad example for this since I barely make backups, and when I do, it’s usually just by zipping the data folder and export in my pc 😅

That said, I really like the Git-based backup approach by the way. I think it’s a pretty cool idea.

[perber]

@EduardSchwarzkopf Let me know if you need guidance or anything else. I’m happy to support!

[EduardSchwarzkopf]

@perber thanks for the help. I'm currently working on it already, and it looks promising. Doind a in depth field test the next few days and will open a PR. If I have any questions, I will let you know.