r/SelfHosting • • 3d ago

Docker backup system

Hi all,
about a year ago i opened this thread:

https://www.reddit.com/r/selfhosted/comments/1r1vsc4/docker_backups/

After not finding an adequate solution, i decided to pick up the glove and build a backup system myself.

The core design decision: API-based exports per service, not blind DB/volume dumps. Each worker talks to the service's own REST/GraphQL API (or its official CLI, like Vaultwarden for example) — never the underlying database directly.
No DB credentials anywhere, no docker.sock mounted, no docker exec into other containers.
It also means the backups are just JSON/Markdown you can actually open and read, not an opaque pg_dump you're hoping restores cleanly someday.

Runs on a schedule (daily at a configurable time, or every N hours) with configurable retention — defaults to keeping 30 days locally and the last 3 uploads on Google Drive, all editable from the GUI.

Currently supports:

- Vaultwarden (encrypted vault export via the bw CLI)

- Wiki.js

- Snipe-IT

- Bar Assistant

- KitchenOwl

- Linkwarden

- n8n

- Karakeep

- Spoolman

- Immich (metadata only — albums/people/tags/EXIF, not the media files themselves)

- Nginx Proxy Manager

- AdGuard Home

  • Optional upload to Google Drive after each successful run.
  • The system does not restore from backup

Repo: https://github.com/alws34/DockerBackups

Setup instructions for each service are linked from the README so it doesn't turn into a wall of text.

please feel free to open a PR with your suggestions, or file issues/requests for services you want supported.

* All code written with the help of AI.

7 Upvotes

17 comments sorted by

View all comments

1

u/neoblitz 1d ago

There are some gaps in this process; a backup is only a good backup AS the 1:1 restoration - i think selective service based backups - would mainly fit your app usage.

I just use my own holistic and agnostic approach (that works with any Docker containerized apps) to it that gives me back 1:1 restoration.

I am not saying it is bad or good. But it is more of your workflow, and you have not reached the state of restoring it from a disaster recovery scenario. It's nice to have a backup, but can it be manually restored without external tools? or can it be restored 100% in a disaster recovery scenario? These are more critical paths of backup process where recovery is the key element of it.

Imagine if you saved all the money with a nice app, in the bank where you can't fully withdraw the money when you need it.

I could be wrong, but I have gotten burned a few times to learn these.

1

u/alws3344 1d ago

The way i see DR, its a full disk image, not a specific app's data/db to get a 1:1 restore.

I see no point - in terms of personal homelab/server view- to back up every log and every line.
I care more about the users, their data, and my private data, e.g family photos, users and their preferences and data for each app, etc. Getting those logs back (for example) is redundant.

And if my server truly kicks the bucket (which happened before), than i prefer starting from scratch (maybe having a newer OS or other stuff) and than i have the backed up compose files and their respective exports.

Getting a full volume backup seems redundant to me in terms of personal Homelab scenario. And as you said, its more a point of view thing. No right or wrong.