Micha/homelab-infra
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
4eea231d2417b2cdadf7e79dc1cad088714b50e4
homelab-infra/ops/borg-ui/BACKUP_AUDIT_STATUS_QUO.md
T

9.5 KiB
Raw Blame History

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/homepage
  • /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
Homepage Config + Bilder 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

Nicht erfolgreich / nicht bestätigt

  • komodo-mongo.archive.gz - im bisherigen Lauf nicht sichtbar, daher noch nicht als bestätigt werten

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

  • komodo-mongo-Dump bleibt unbestätigt
  • Dump-Automatisierung vor dem Borg-Lauf fehlt noch
  • der Scope kann später noch bewusst verschlankt werden, ist aber aktuell funktionsfähig

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 noch nicht bestätigt

  2. Automatisierung

    • Dumps wurden manuell erzeugt
    • die festgelegte Zielrichtung ist jetzt host-seitig über Unraid User Scripts / Host-Cron
    • eine saubere Pre-Backup-Automatisierung ist noch nicht final eingebunden

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
  • fehlende Automatisierung

Nächste sinnvolle Schritte

  1. Den erfolgreichen ersten critical_infra-Lauf als bestätigt festhalten und nur die verbleibenden Restpunkte weiterverfolgen.
  2. Die offenen Restpunkte gegen den Audit halten:
    • komodo-mongo weiterhin als unbestätigt markieren
    • Dump-Automatisierung als nächsten echten Umsetzungsblock behandeln
    • dafür host-seitig über Unraid User Scripts / Host-Cron arbeiten, nicht über Borg-UI-Inline-Hooks
    • optionale spätere Scope-Verschlankung nur bewusst und nicht ad hoc vornehmen
  3. Erst danach entscheiden:
    • ob Pfade umgezogen werden müssen
    • wie die Pre-Backup-Dumps automatisiert werden

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 erfolgreichen ersten critical_infra-Lauf dokumentarisch abschließen und die verbleibenden Restpunkte sauber abgrenzen.
  2. Pre-Backup-Dumps vor Borg automatisieren.
    • Zielweg: host-seitig über Unraid User Scripts / Host-Cron
    • nicht als Borg-UI-Inline-Hook in der aktuellen Architektur
  3. Repo-Soll gegen Live-Ist prüfen und nur bei echtem Drift gezielt eingreifen.
  4. Operative Borg-Artefakte nach /mnt/user/backups/borg/dumps verlagern und dort dauerhaft vom Live-App-State trennen.

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.
Reference in New Issue View Git Blame Copy Permalink