Skip to content

About

A small, self-contained Docker container that copies Trilium's own automatic backup snapshots off your server and onto a network destination (NAS, another server, anywhere Docker can mount a folder), with retention pruning and a permanent, never-overwritten baseline copy.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

4 Commits

Folders and files

Repository files navigation

Trilium NAS Backup

A small, self-contained Docker container that copies Trilium's own automatic backup snapshots off your server and onto a network destination (NAS, another server, anywhere Docker can mount a folder), with retention pruning and a permanent, never-overwritten baseline copy.

Why this exists

Trilium already creates safe, consistent backup snapshots on its own (backup-daily.db, backup-weekly.db, backup-monthly.db), on a schedule you configure inside Trilium itself. The problem: those snapshots live on the same disk as Trilium, right next to the data they're backing up. If that disk fails, your backups fail with it.

This container doesn't create backups — Trilium already does that safely. It just gets copies of those backups to somewhere else, on a schedule, and keeps a bounded history instead of a single overwritten file per interval.

What it does

  • Runs on a daily cron schedule (3 AM by default) inside a lightweight Alpine container
  • Copies Trilium's daily/weekly/monthly backup files to timestamped copies on your chosen destination
  • Prunes old copies, keeping only the N most recent per interval (configurable)
  • Keeps one permanent baseline copy per interval that's never deleted or overwritten, as a last-resort fallback
  • Logs every run (start, completion, and any warnings) to a daily log file
  • Fully configured via environment variables — no need to edit the script

Prerequisites

  • Docker and Docker Compose
  • A running Trilium instance with automatic backups enabled (Trilium's own Options → Backup screen)
  • A destination folder Docker can mount — a network share (NFS/SMB) already mounted on the host, a second disk, another server, etc.

Setup

  1. Clone this repo and cd into it.
  2. Copy the example environment file and fill in your real paths:
    cp .env.example .env
    nano .env
  3. Build and start the container:
    docker compose up -d --build
  4. (Optional but recommended) trigger a manual run to confirm everything's wired up correctly, rather than waiting until 3 AM:
    docker compose exec trilium-backup /usr/local/bin/backup.sh
  5. Check the log to confirm:
    cat <your NAS_BACKUP_DEST>/logs/Log_$(date +%Y-%m-%d).txt

Configuration

All configuration is done via environment variables, either in .env (used by docker-compose.yml) or directly under the environment: block.

Variable Default Description
TRILIUM_BACKUP_SRC (required, set in .env) Path on the host to Trilium's backup/ folder (contains backup-daily.db etc.)
NAS_BACKUP_DEST (required, set in .env) Path on the host to your backup destination
KEEP_DAILY 7 Number of daily snapshots to retain
KEEP_WEEKLY 8 Number of weekly snapshots to retain
KEEP_MONTHLY 12 Number of monthly snapshots to retain

How it works

  • Dockerfile builds a minimal Alpine image with bash and crond, bakes in backup.sh, and installs crontab.txt as the container's cron schedule.
  • docker-compose.yml mounts Trilium's backup folder read-only (this container never modifies Trilium's own files) and your destination read-write, then builds and runs the image.
  • backup.sh does the actual work: for each interval (daily/weekly/monthly), it copies the current snapshot to a timestamped file in a per-interval subfolder, prunes anything beyond the configured retention count, and — the first time only — copies a permanent baseline into a separate baseline/ folder that's never touched again.
  • crond runs inside the container in the foreground, waking up once a minute to check the schedule, keeping the container alive indefinitely with no separate host-level cron needed.

Notes / limitations

  • This assumes Trilium's own automatic backups are enabled and working — this tool only relocates files Trilium already created, it doesn't create backups itself.
  • Weekly/monthly copies will show a warning in the log until Trilium's own weekly/monthly backup has actually run at least once (7 days / 1 month after Trilium was first set up) — this is expected, not an error.
  • Retention counts backups by count, not by age — e.g. KEEP_DAILY=7 keeps the 7 most recent daily copies regardless of gaps.
  • You will need a NAS Device of your own choosing that supports NFS for this to work - I tested this on a Synology NAS without any Issues ,but your mileage may vary depending on what your NAS supports or does not support !

License

GPL-3.0 — see LICENSE

About

A small, self-contained Docker container that copies Trilium's own automatic backup snapshots off your server and onto a network destination (NAS, another server, anywhere Docker can mount a folder), with retention pruning and a permanent, never-overwritten baseline copy.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages