Remove Firefly and Semaphore from homelab

ops/borg-ui/BACKUP_AUDIT_STATUS_QUO.md

@@ -50,7 +50,6 @@ Der technische Scope für `critical_infra` ist in `all-important-sources.txt` fe
 - `/local/immich/external`
 - `/local/gitea/data`
 - `/local/appdata/mealie/data`
-- `/local/appdata/firefly/upload`
 - `/local/appdata/mailarchiver/data-protection-keys`
 
 ### Secrets / Konfiguration / Infrastruktur
@@ -85,8 +84,6 @@ Der technische Scope für `critical_infra` ist in `all-important-sources.txt` fe
 | 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 |
-| Firefly | Uploads | MariaDB Dump scheitert aktuell an korruptem Table | Teilweise | offen, aber niedrige Priorität wenn Ablösung geplant |
-| Semaphore | Docker named volumes | Shared PostgreSQL vorgesehen, App-Volumes nicht in Borg | Nein / Teilweise | Lücke |
 | 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 |
@@ -98,14 +95,12 @@ Der technische Scope für `critical_infra` ist in `all-important-sources.txt` fe
 - `postgresql17-globals.sql`
 - `postgresql17-mailarchiver.dump`
 - `postgresql17-paperless.dump`
-- `postgresql17-semaphore.dump`
 - `postgresql17-authelia.dump`
 - `mealie.dump`
 - `immich.dump`
 
 ### Nicht erfolgreich / nicht bestätigt
 
-- `firefly.sql` - Dump scheitert aktuell an korruptem MariaDB-Table `rt_meta`
 - `komodo-mongo.archive.gz` - im bisherigen Lauf nicht sichtbar, daher noch nicht als bestätigt werten
 
 ## Ergebnis des ersten `critical_infra`-Laufs
@@ -160,17 +155,7 @@ Das ist kein Strukturfehler, sondern eine normale Trennung zwischen Nutzdaten un
    - Dump-Pfad im Skript vorhanden
    - Erfolg noch nicht bestätigt
 
-2. **Semaphore**
-   - PostgreSQL-Teil ist grundsätzlich dumpbar
-   - die App selbst nutzt aber Docker named volumes
-   - diese Volumes sind aktuell nicht sauber im Borg-Scope enthalten
-
-3. **Firefly**
-   - Datei-Uploads sind enthalten
-   - DB-Dump aktuell fehlerhaft
-   - wenn Firefly sowieso bald entfernt wird, ist das momentan nicht blockierend
-
-4. **Automatisierung**
+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
@@ -191,7 +176,6 @@ Das eigentliche Restproblem ist aktuell **nicht** die Share-Struktur, sondern:
 
 - einzelne noch offene Dump-Kandidaten
 - fehlende Automatisierung
-- einzelne Spezialfälle wie Semaphore named volumes
 
 ## Nächste sinnvolle Schritte
 
@@ -203,7 +187,6 @@ Das eigentliche Restproblem ist aktuell **nicht** die Share-Struktur, sondern:
    - optionale spätere Scope-Verschlankung nur bewusst und nicht ad hoc vornehmen
 3. Erst danach entscheiden:
    - ob Pfade umgezogen werden müssen
-   - ob Firefly schlicht ausläuft statt weiter bereinigt zu werden
    - wie die Pre-Backup-Dumps automatisiert werden
 
 ## Festgehaltene Entscheidung
@@ -232,11 +215,6 @@ Stand jetzt werden **keine grundlegenden Share-Umstrukturierungen** vorgenommen.
 - `services/gitea` bleibt an Ort und Stelle.
 - `appdata` wird aktuell nicht großflächig bereinigt oder umgebaut.
 
-### Einfluss von Firefly und Semaphore
-
-- `Semaphore` ist als zukünftige Löschung eingeplant und wird deshalb **nicht** mehr durch Strukturmaßnahmen optimiert.
-- `Firefly` ist ebenfalls als zukünftige Löschung eingeplant und wird deshalb **nicht** mehr durch Strukturmaßnahmen optimiert.
-
 ### Aktuelle Prioritäten statt Share-Umbau
 
 1. Den erfolgreichen ersten `critical_infra`-Lauf dokumentarisch abschließen und die verbleibenden Restpunkte sauber abgrenzen.