Lumio / self-hosted
Anleitung

Lumio sichern und wiederherstellen.

Self-Hosting heißt: die Sicherung liegt bei dir. Diese Anleitung zeigt genau, was gesichert werden muss, wie du es automatisierst und wie ein Restore im Ernstfall abläuft.

Was gesichert werden muss

Drei Dinge — nur zusammen ergeben sie ein vollständiges Backup:

  • Die PostgreSQL-Datenbank — Galerien, Benutzer, Einstellungen, Metadaten
  • Die Objektdaten — die eigentlichen Bilder/Videos (MinIO-Volume oder externer S3-Bucket)
  • Die .env — enthält die Schlüssel; ohne sie kommst du an die Objektdaten nicht mehr heran

Faustregel: Datenbank täglich, Objektdaten je nach Änderungsrate, und immer eine Kopie außer Haus.

Datenbank sichern

Ein pg_dump im laufenden Betrieb, aus dem Projektverzeichnis:

cd /opt/lumio
docker compose exec -T postgres pg_dump -U lumio lumio > db_$(date +%F).sql

# platzsparend gleich komprimieren
docker compose exec -T postgres pg_dump -U lumio lumio | gzip > db_$(date +%F).sql.gz

Objektdaten sichern

Bei mitgeliefertem MinIO liegen die Dateien in einem Docker-Volume (meist lumio_minio_data — prüfe mit docker volume ls). Sichere es mit einem kleinen Helfer-Container:

docker run --rm \
  -v lumio_minio_data:/data:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/minio_$(date +%F).tar.gz -C /data .

Und die .env nicht vergessen — einfach mitkopieren (sie ist sensibel, sicher aufbewahren):

cp /opt/lumio/.env env_$(date +%F).backup

Automatisieren & außer Haus kopieren

Pack die Schritte in ein kleines Skript und lass es per Cron laufen. Die entscheidende Zutat ist die Kopie an einen zweiten Ort — anderer Datenträger, anderes Gebäude oder ein Object-Storage-Bucket. Mit rclone geht Letzteres in einer Zeile:

# Beispiel: Backups nach der Sicherung off-site schieben
rclone copy /opt/lumio/backups remote:lumio-backups

# Cron: täglich 3:15 Uhr (crontab -e)
15 3 * * * /opt/lumio/backup.sh >> /var/log/lumio-backup.log 2>&1

Ältere Backups regelmäßig aufräumen (z.B. 14 Tage behalten), damit der Speicher nicht vollläuft.

Wiederherstellen (Ernstfall)

Auf einer frischen Maschine: Lumio wie gewohnt installieren, aber die gesicherte .env verwenden (gleiche Schlüssel = die Objektdaten passen wieder). Dann Daten zurückspielen:

cd /opt/lumio
cp /pfad/zum/backup/.env .env      # gesicherte .env einsetzen

# Objektdaten ins Volume zurück (Stack darf noch aus sein)
docker volume create lumio_minio_data
docker run --rm \
  -v lumio_minio_data:/data \
  -v /pfad/zum/backup:/backup \
  alpine sh -c "tar xzf /backup/minio_JJJJ-MM-TT.tar.gz -C /data"

# Stack starten (legt die leere DB an)
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

# Datenbank einspielen
gunzip < /pfad/zum/backup/db_JJJJ-MM-TT.sql.gz | \
  docker compose exec -T postgres psql -U lumio lumio

Danach einloggen und eine Galerie öffnen — Bilder und Metadaten sollten vollständig da sein.

Häufige Fragen zu Backup & Restore

Wie oft sollte ich sichern? +

Die Datenbank täglich (sie ist klein und der Dump geht schnell), die Objektdaten je nach Änderungsrate — bei aktivem Betrieb täglich, sonst wöchentlich. Wichtig ist weniger die Frequenz als die Regel: automatisiert per Cron und mit einer Kopie außer Haus. Ein Backup, das nur auf demselben Gerät liegt, ist kein Backup.

Warum muss ich die .env mitsichern? +

Weil dort die Secrets stehen — unter anderem S3_ACCESS_KEY und S3_SECRET_KEY. Ohne diese Schlüssel kommst du an deine gesicherten MinIO-Objektdaten nicht mehr heran, und ohne JWT_SECRET/SESSION_SECRET verhalten sich Sessions nach einem Restore seltsam. Die .env gehört also zwingend zur Sicherung (und an einen sicheren Ort, sie ist sensibel).

Muss Lumio für ein Backup gestoppt werden? +

Nein. pg_dump erzeugt einen konsistenten Snapshot bei laufender Datenbank. Die Objektdaten sind unveränderliche Dateien (neue Uploads kommen dazu, bestehende ändern sich nicht) — ein Kopieren im Betrieb ist unkritisch. Nur für einen sauberen Volume-Snapshot bei sehr hoher Schreiblast kann ein kurzes Stoppen sinnvoll sein.

Reicht es, nur die Datenbank zu sichern? +

Nein. Die Datenbank enthält Galerien, Benutzer, Einstellungen — aber nicht die Bilder. Die liegen als Objektdaten (im MinIO-Volume oder im externen S3-Bucket). Du brauchst beide Teile, sonst hast du nach einem Restore leere Galerien oder Bilder ohne Zuordnung.

Was ist mit externem S3 (Hetzner, B2)? +

Dann liegen die Objektdaten nicht lokal, sondern im Bucket. Sichere sie über die Bordmittel des Anbieters: Versionierung plus Lifecycle-Regel, oder ein regelmäßiges mc mirror in einen zweiten Bucket bei einem anderen Anbieter. Die Datenbank und die .env sicherst du wie unten beschrieben ganz normal.

Bereit für deine eigene Galerie?

Source-Code auf GitHub, Fragen und Diskussionen ebenfalls dort. Wenn in der Anleitung etwas hakt, melde dich — wir verbessern die Docs gerne.