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//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 ``` 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