homelab-infra/ops/borg-ui/BACKUP_AUDIT_STATUS_QUO.md

Backup Audit - Status Quo

Stand: 2026-04-15

Dieses Dokument beschreibt den aktuellen Ist-Zustand des Homelab-Backups, bevor weitere Strukturänderungen oder Migrationsschritte vorgenommen werden.

Ziel dieses Audits

1. Festhalten, welche Daten wo liegen.
2. Prüfen, was aktuell im Borg-Scope enthalten ist.
3. Sichtbar machen, welche Lücken oder Unsicherheiten noch bestehen.
4. Erst danach über Umzüge oder Bereinigungen entscheiden.

Shares - fachliche Einordnung

Share	Aktuelle Rolle	Bewertung
appdata	App-Konfig, Datenbanken, App-State, Secrets	fachlich normal, aber gemischt; nicht alles daraus sollte pauschal gebackupt werden
documents	Nutzdaten für Dokumente / Paperless	fachlich sauber
photos	Nutzdaten für Bilder / Immich / Archiv	fachlich sauber
services	GitOps / Infrastruktur / Gitea / Compose	fachlich sauber
backups	Backup-Ziele und Restore-Daten	sollte frei von Live-App-Daten bleiben
media	Mediathek / große Inhaltsdaten	aktuell nicht Teil des Critical-Scopes
finance	sensible Nutzdaten	aktuell nicht Teil des Critical-Scope
projekte	Projekt- und Entwicklungsdaten	aktuell nicht Teil des Critical-Scope

Aktueller Borg-Zielzustand

Es gibt derzeit zwei relevante Ebenen:

1. Ein älteres breites Test-Repository (hetzner_borg-appdata), das nicht als finales Design gewertet werden sollte.
2. Ein neues gezieltes Critical-Repository (critical_infra), das den fachlich wichtigen Scope abdecken soll.

Der technische Scope für critical_infra ist in all-important-sources.txt festgehalten.

Aktueller Borg-Scope - Quellen

Dumps

• /local/borg-dumps

Kritische App-/Nutzdaten

• /local/appdata/vaultwarden
• /local/appdata/paperless-ngx/data
• /local/paperless/media
• /local/paperless/export
• /local/paperless/consume
• /local/immich/upload
• /local/immich/external
• /local/gitea/data
• /local/appdata/mealie/data
• /local/appdata/mailarchiver/data-protection-keys

Secrets / Konfiguration / Infrastruktur

• /local/secrets
• /local/appdata/authelia/config
• /local/appdata/traefik
• /local/appdata/ntfy
• /local/appdata/paperless-gpt
• /local/appdata/tailscale
• /local/appdata/adguard/conf
• /local/appdata/borg-ui/data
• /local/appdata/komodo/periphery
• /local/appdata/komodo/core

Service-Audit

Service	Nutzdaten	DB / technischer Zustand	Aktuell durch Borg abgedeckt?	Bewertung
Vaultwarden	/mnt/user/appdata/vaultwarden	Datei-basiert	Ja	gut
Paperless	documents + appdata/paperless-ngx/data	Shared PostgreSQL Dump vorhanden	Ja	gut
Immich	/mnt/user/photos/immich, /mnt/user/photos/family_archive	eigener PostgreSQL Dump vorhanden	Ja	gut
Gitea	/mnt/user/services/gitea/data	SQLite in /data	Ja	gut
Mealie	/mnt/user/appdata/mealie/data	eigener PostgreSQL Dump vorhanden	Ja	gut
Mail-archiver	DataProtection-Keys	Shared PostgreSQL Dump vorhanden	Ja	gut
Authelia	Config + Secrets	Shared PostgreSQL Dump vorgesehen / erzeugt	Ja	gut
Traefik	dynamische Config + Let's Encrypt	keine separate DB	Ja	gut
ntfy	Datei-Daten	keine separate DB	Ja	gut
Paperless-GPT	lokale Daten / Prompts	keine separate DB	Ja	gut
Tailscale	State-Verzeichnis	keine separate DB	Ja	gut
AdGuard	conf	work bewusst nicht im Critical-Scope	Teilweise	okay
Komodo	core + periphery	MongoDB Dump aktuell nicht verifiziert	Teilweise	offen
Redis	transiente Daten / Cache	absichtlich nicht im Scope	Nein	bewusst ausgeschlossen
Scrutiny	Config + InfluxDB	InfluxDB nicht im Scope	Nein	bewusst ausgeschlossen
Plex	Medien-Metadaten / Cache	kein Critical-Scope	Nein	bewusst ausgeschlossen

Datenbank-Dumps - Ist-Zustand

Erfolgreich erzeugt

• postgresql17-globals.sql
• postgresql17-mailarchiver.dump
• postgresql17-paperless.dump
• postgresql17-authelia.dump
• mealie.dump
• immich.dump

Bestätigt

• komodo-mongo.archive.gz - am 2026-05-04 frisch erzeugt und per gzip -t geprüft

Ergebnis des ersten critical_infra-Laufs

Der erste vollständige Lauf des neuen Borg-Repositories critical_infra wurde erfolgreich abgeschlossen.

Bestätigter Lauf

• Repository: ssh://u565255@u565255.your-storagebox.de:23/./hetzner_borg_appdata_critical
• Archiv: manual-backup-2026-04-13T19:19:52
• Status: erfolgreich (rc 0)
• Laufzeit: 1h 37m 12s
• Dateien: 63.237
• Archivgröße: 24,73 GB original / 24,53 GB komprimiert / 23,37 GB dedupliziert

Bedeutung

Damit ist bestätigt, dass der aktuelle Critical-Scope technisch durch Borg gesichert werden kann.

Das betrifft insbesondere:

• Paperless-Dokumente und zugehörige Dumps
• Immich-Uploads und photos/family_archive
• Gitea-Daten
• Vaultwarden
• Secrets / Traefik / Authelia
• die aktuell erzeugten PostgreSQL-Dumps

Weiterhin offen trotz erfolgreichem Lauf

• der Scope kann später noch bewusst verschlankt werden, ist aber aktuell funktionsfähig

Aktueller Abschlussstand

Seit dem ersten erfolgreichen Lauf wurde der Zielzustand weiter konkret umgesetzt:

• Die Pre-Backup-Dumps laufen host-seitig über Unraid User Scripts / Host-Cron.
• Der Dump-Zielpfad wurde nach /mnt/user/backups/borg/dumps verlagert.
• Der neue Zielpfad ist im laufenden borg-ui-Container sichtbar.
• Ein Restore-Smoke-Test war erfolgreich:
  • postgresql17-globals.sql wurde wiederhergestellt
  • gitea.db wurde wiederhergestellt
• ntfy und Uptime Kuma sind für Borg-Monitoring eingerichtet.
• Firefly, Firefly-Fints und Semaphore wurden aus Git und vom Homelab entfernt.

Was aktuell bewusst nicht als Problem gewertet wird

• photos/family_archive liegt fachlich korrekt im Share photos und wird durch Borg gesichert.
• Paperless liegt absichtlich über mehrere Shares verteilt:
  • documents für Nutzdaten
  • appdata für App-State
  • Dump für DB
• Immich liegt absichtlich über mehrere Bereiche verteilt:
  • photos für Bilder
  • appdata für DB
  • Dump für DB

Das ist kein Strukturfehler, sondern eine normale Trennung zwischen Nutzdaten und App-State.

Aktuelle Lücken / offene Entscheidungen

1. Komodo MongoDB
   • Dump-Pfad im Skript vorhanden
   • Erfolg am 2026-05-04 bestätigt

Vorläufiges Audit-Fazit

Der aktuelle Borg-Scope ist nicht chaotisch, sondern bereits deutlich strukturierter als ein pauschales Backup von /mnt/user/appdata.

Fachlich sieht das Bild aktuell so aus:

• appdata = technischer App-State
• documents = Paperless-/Dokumenten-Nutzdaten
• photos = Immich-/Bild-Nutzdaten
• services = GitOps / Gitea / Infra
• backups = Backup-Ziel, nicht Live-Daten

Das eigentliche Restproblem ist aktuell nicht die Share-Struktur, sondern:

• einzelne noch offene Dump-Kandidaten

Nächste sinnvolle Schritte

1. komodo-mongo nach Komodo-Major-Upgrades gezielt im Auge behalten.
2. Das automatische Borg-Fenster beobachten und nach den ersten geplanten Läufen nur noch auf Warnungen reagieren.
3. Optionale spätere Scope-Verschlankung nur bewusst und nicht ad hoc vornehmen.

Festgehaltene Entscheidung

Stand jetzt werden keine grundlegenden Share-Umstrukturierungen vorgenommen.

Begründung

• Die aktuelle Share-Struktur ist fachlich grundsätzlich brauchbar:
  • appdata = technischer App-State
  • documents = Dokument-Nutzdaten
  • photos = Bild-/Immich-Nutzdaten
  • services = GitOps / Infrastruktur
  • backups = Backup-Ziel
• Der erwartete Ertrag eines großen Share-Umbaus ist aktuell niedrig.
• Das Risiko eines Umbaus ist vergleichsweise hoch, weil Live-Pfade, Compose-Mounts und Backup-Quellen gleichzeitig betroffen wären.
• Der aktuelle Engpass liegt nicht in den Shares selbst, sondern in:
  • vollständiger Borg-Abdeckung
  • sauberer Dump-Automatisierung
  • einzelnen offenen Spezialfällen

Spezifische Bewertung

• photos/family_archive bleibt an Ort und Stelle.
• documents-Pfade für Paperless bleiben an Ort und Stelle.
• services/gitea bleibt an Ort und Stelle.
• appdata wird aktuell nicht großflächig bereinigt oder umgebaut.

Aktuelle Prioritäten statt Share-Umbau

1. Den automatischen Betrieb beobachten statt die Architektur weiter umzubauen.
2. Repo-Soll und Live-Ist nur bei echtem Drift erneut vergleichen.
3. komodo-mongo bei Bedarf separat bewerten.

Erläuterung zu Punkt 4

Diese Änderung wird ausdrücklich als klein, risikoarm und sinnvoll bewertet:

• Dump-Dateien und Borg-Staging-Daten sind Backup-Artefakte, keine eigentlichen App-Daten.
• Der Zielpfad /mnt/user/backups/borg/dumps ist fachlich sauberer als appdata/borg-ui/dumps.
• Der erwartete Nutzen ist höher als bei kosmetischen Share-Umbauten, weil die Trennung zwischen Live-System und Backup-Artefakten klarer wird.

Festgelegtes Ziel:

• /mnt/user/backups/borg/dumps

Wichtig:

• Diese Änderung bleibt klein und risikoarm, weil nur Dump-Artefakte umziehen.
• Die Live-App-Datenpfade bleiben davon unberührt.