syncova-backup/.gitea/ISSUE_TEMPLATE/fehler.yaml

name: Fehler melden
about: Etwas verhält sich anders, als es soll
title: "[Fehler] "
body:
  - type: markdown
    attributes:
      value: |
        ## Bevor Sie schreiben: ist es wirklich ein Fehler?

        Sieben Dinge sehen wie ein Fehler aus und sind gewolltes Verhalten. Ein
        Blick darauf spart Ihnen und mir einen halben Tag:

        | Beobachtung | Warum es richtig ist |
        | --- | --- |
        | Durchsetzungsstufe `advisory` statt `filesystem` | Ihr Dateisystem setzt den Löschschutz nicht durch — overlayfs, NFS oder fehlendes `CAP_LINUX_IMMUTABLE`. Die Stufe wird **gemessen**, nicht behauptet |
        | `PARTIAL FAILURE` bei nicht lesbarer Datei | Dort fehlen Daten. Ein Teilfehler ist kein Erfolg und wird bewusst nicht wiederholt |
        | Sockets, Pipes, Gerätedateien werden übergangen | Sie haben keinen sicherbaren Inhalt. Das ist ein Vermerk, kein Fehler |
        | „Gelöscht, aber nichts frei geworden" | Deduplizierung: Die Blöcke werden von einem anderen Backup gebraucht |
        | Erfolgsquote meldet `warning` bei 100 % | Es gab keine Läufe. Ohne Lauf gibt es keine Quote |
        | `503` mit vollständigem `data`-Bericht | Absicht: Monitoring schlägt an, die Oberfläche kann trotzdem zeigen, *was* kaputt ist |
        | Punkt bleibt `unverified` trotz sauberem Scan | Nur ein durchgeführter Wiederherstellungstest hebt auf `recoverable`. Alles davor ist ein Indiz |

        Weitere Fälle nach Symptom: [`docs/troubleshooting.md`](../src/branch/main/docs/troubleshooting.md)

        ---

        ## Keine Geheimnisse einfügen

        **Niemals** in ein Issue: `SYNCOVA_ENCRYPTION_KEYS`, `SYNCOVA_DB_PASSWORD`,
        API-Tokens, Zugangsdaten der Virtualisierungsverbünde.

        Das Diagnoseskript unten entfernt sie selbsttätig. Sehen Sie den Bericht
        trotzdem durch, bevor Sie ihn einfügen — er ist danach öffentlich.        

  - type: textarea
    id: beobachtung
    attributes:
      label: Was ist passiert?
      description: Was haben Sie gesehen — möglichst mit der genauen Meldung.
      placeholder: |
        Beim nächtlichen Lauf des Auftrags "Dateiserver täglich" bricht die
        Sicherung nach etwa zwei Minuten ab. Die Oberfläche zeigt den Lauf als
        "failed" mit dem Code REPOSITORY_FULL, obwohl auf dem Ziel 400 GB frei sind.        
    validations:
      required: true

  - type: textarea
    id: erwartung
    attributes:
      label: Was haben Sie erwartet?
      description: |
        Bitte ausfüllen, auch wenn es offensichtlich scheint. Oft liegt genau
        hier der Unterschied zwischen einem Fehler und einer Erwartung, die die
        Anlage bewusst nicht erfüllt.        
      placeholder: Der Lauf sollte durchlaufen; es ist genug Platz vorhanden.
    validations:
      required: true

  - type: textarea
    id: schritte
    attributes:
      label: Wie lässt es sich auslösen?
      description: |
        Schritt für Schritt. Wenn es nur sporadisch auftritt, schreiben Sie das
        — auch „nur nachts, etwa jeder dritte Lauf" ist eine brauchbare Angabe.        
      placeholder: |
        1. Auftrag mit Quelle /srv/daten und Repository /mnt/backup anlegen
        2. Lauf über POST /api/v1/jobs/<id>/run anstoßen
        3. Nach ~2 Minuten steht der Lauf auf failed        
    validations:
      required: true

  - type: input
    id: fehlercode
    attributes:
      label: Fehlercode und request_id
      description: |
        **Die beiden wertvollsten Angaben überhaupt.** Der Code steht in
        `error.code` jeder API-Antwort und im Lauf; die `request_id` steht in
        **jeder** Antwort — auch der erfolgreichen. Ohne sie bleibt „es hat
        nicht funktioniert".        
      placeholder: "REPOSITORY_FULL, request_id 7f900328-a7db-4c54-ae6e-9ace38353224"

  - type: dropdown
    id: bereich
    attributes:
      label: Welcher Bereich?
      description: Grobe Zuordnung genügt — sie grenzt die Suche stark ein.
      options:
        - Weiß ich nicht
        - Sicherung (Scheduler, Backup Engine)
        - Wiederherstellung
        - Repository (Integrität, Katalog, Löschschutz)
        - Agent (Windows oder Linux)
        - Proxmox
        - Oberfläche
        - API
        - Anmeldung, Rollen, zweiter Faktor
        - Meldungen und Benachrichtigungen
        - Kennzahlen und Berichte
        - Installation, Update, Deinstallation
    validations:
      required: true

  - type: dropdown
    id: datenrisiko
    attributes:
      label: Sind Daten in Gefahr?
      description: |
        Bestimmt die Reihenfolge der Bearbeitung. Bitte ehrlich einschätzen —
        „weiß ich nicht" ist eine zulässige und nützliche Antwort.        
      options:
        - Nein — es ist unschön, aber nichts geht verloren
        - Weiß ich nicht
        - Ja — eine Sicherung fehlt oder ist unvollständig
        - Ja — eine Wiederherstellung liefert falsche oder fehlende Daten
        - Ja — Daten wurden gelöscht oder sind unlesbar
    validations:
      required: true

  - type: dropdown
    id: haeufigkeit
    attributes:
      label: Wie oft tritt es auf?
      options:
        - Jedes Mal
        - Häufig, aber nicht immer
        - Selten
        - Genau einmal
    validations:
      required: true

  - type: textarea
    id: diagnose
    attributes:
      label: Diagnosebericht
      description: |
        Auf dem betroffenen Server ausführen und die **vollständige** Ausgabe
        hier einfügen:

        ```bash
        sudo /opt/syncova/diagnose.sh
        ```

        Liegt das Skript nicht dort, steht es im entpackten Paket neben
        `setup.sh`. Es liest nur und **verändert nichts**; Geheimnisse entfernt
        es selbsttätig.

        Es sammelt in einem Zug: Fassungen aller Programme, Betriebssystem,
        Container ja/nein, **Dateisystem des Repositorys**, PostgreSQL-Fassung,
        Schemastand, Dienstzustand, Gesundheitsbericht, Bestand, die letzten
        nicht erfolgreichen Läufe mit Fehlercode, gemessene Durchsetzungsstufe
        und die letzten Fehlerzeilen.

        Ohne diesen Bericht folgen als Erstes Rückfragen nach genau diesen Werten.        
      render: text
    validations:
      required: true

  - type: textarea
    id: protokoll
    attributes:
      label: Protokollzeilen zum Vorfall
      description: |
        Wenn Sie die `request_id` haben, ist das die kürzeste Suche:

        ```bash
        journalctl -u syncova-api --no-pager | grep <request-id>
        ```

        Sonst die Zeilen um den Zeitpunkt herum:

        ```bash
        journalctl -u syncova-api --since "2026-08-17 02:00" --until "2026-08-17 02:10" --no-pager
        ```

        Prüfen Sie die Zeilen auf Pfade und Namen, die nicht öffentlich werden sollen.        
      render: text

  - type: textarea
    id: sonstiges
    attributes:
      label: Sonstiges
      description: |
        Was Ihnen sonst auffiel. Besonders nützlich: Hat es früher funktioniert?
        Wurde etwas geändert — Update, neue Platte, neues Netz, Umzug des
        Repositorys?        

  - type: checkboxes
    id: bestaetigung
    attributes:
      label: Vor dem Absenden
      options:
        - label: Ich habe die Tabelle oben durchgesehen; es ist keiner dieser Fälle
          required: true
        - label: Der Bericht enthält keine Passwörter, Schlüssel oder Tokens
          required: true
        - label: Ich verwende die Fassung, die im Diagnosebericht steht
          required: true