239 lines
9.1 KiB
Markdown
239 lines
9.1 KiB
Markdown
# 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`
|
|
|
|
### 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.
|