# 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.