# Longhorn Health Report

Quelle: read-only `kubectl` Longhorn CRDs. Keine Änderungen durchgeführt.

## Kernaussage
Longhorn läuft, aber *alle 12 sichtbaren Longhorn-Volumes sind nicht `healthy`*: 11 sind `attached/degraded`, 1 ist `detached/unknown`. Hauptursache sehr wahrscheinlich: Longhorn/StorageClass erwartet 3 Replicas, der Cluster hat aber nur 2 Longhorn-Nodes. Dadurch kann Longhorn die gewünschte Replica-Anzahl nie vollständig erreichen.

## Longhorn Nodes / Disks
| Node | AllowScheduling | Disk | Frei | Max |
|---|---:|---|---:|---:|
| `mbrkanov-mini-it13` | True | `/var/lib/longhorn/` | 1316.9Gi | 1372.6Gi |
| `mini-it13-02` | True | `/var/lib/longhorn/` | 724.5Gi | 767.9Gi |

## Relevante Settings
- `default-replica-count`: `3`
- `replica-soft-anti-affinity`: `false`
- `storage-over-provisioning-percentage`: `100`
- `storage-minimal-available-percentage`: `25`
- `backup-target`: ``
- StorageClass `longhorn`: `numberOfReplicas: 3`
- Effekt: In einem 2-Node-Cluster sind 3 echte Node-redundante Replicas nicht erreichbar.

## Volumes / PVC-Zuordnung
| Namespace | PVC | Size | State | Robustness | Attached Node | Running Replicas | Stopped Replicas |
|---|---|---:|---|---|---|---:|---:|
| `hf-espocrm` | `data-hf-espocrm-mariadb-0` | 8Gi | attached | degraded | `mini-it13-02` | 2 | 1 |
| `hf-matomo` | `matomo-db-pvc` | 1Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |
| `hf-matomo` | `matomo-pvc` | 1Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |
| `hf-mautic` | `data-hf-mautic-mariadb-0` | 10Gi | attached | degraded | `mini-it13-02` | 2 | 1 |
| `hf-mautic` | `redis-data-hf-mautic-redis-master-0` | 5Gi | attached | degraded | `mini-it13-02` | 2 | 1 |
| `hf-n8n` | `n8n` | 5Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |
| `hf-suitecrm` | `data-suitecrm-mariadb-0` | 10Gi | attached | degraded | `mini-it13-02` | 2 | 1 |
| `hf-suitecrm` | `suitecrm-suitecrm` | 10Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |
| `homarr` | `my-homarr-config` | 10Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |
| `homarr` | `my-homarr-data-mb` | 10Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |
| `homarr` | `my-homarr-data-new` | 100Gi | detached | unknown | `` | 0 | 2 |
| `homarr` | `my-homarr-icons` | 10Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |

## Backup-Status
- Longhorn `backuptarget/default`: `AVAILABLE=false`; URL leer/nicht gesetzt.
- Damit ist kein funktionierendes Longhorn Backup Target sichtbar.

## Bewertung
- Die `degraded`-Anzeige ist strukturell erklärbar: 3 gewünschte Replicas bei nur 2 Nodes.
- Das reduziert nicht zwingend sofort die Verfügbarkeit aller Apps, aber es bedeutet: Longhorn befindet sich dauerhaft außerhalb des gewünschten Zielzustands.
- Kritischer ist die Kombination mit Datenbank-Problemen bei EspoCRM/SuiteCRM und fehlendem Backup Target.

## Empfohlene Reihenfolge
1. Backup-Ziel/Backup-Strategie klären, bevor Longhorn repariert/geändert wird.
2. Ziel-Replica-Count für 2-Node-Betrieb festlegen: realistisch `2`, nicht `3`.
3. Danach Longhorn Settings/StorageClass und existierende Volumes geplant angleichen.
4. Anschließend Datenbank-Pods prüfen: EspoCRM, SuiteCRM, Mautic.

## Needs OK
- Noch keine Änderung durchgeführt.
- Jede Änderung an Longhorn Settings, StorageClass, Replicas oder Volumes braucht dein explizites OK.