Commit Graph

2 Commits

Author SHA1 Message Date
4762fa29c3 Fehlervorlage und ein Diagnoseskript, das sie fuellt
Some checks failed
CI / Backend (Go) (push) Failing after 31s
CI / Frontend (React/TypeScript) (push) Successful in 34s
CI / Sicherheitsprüfungen (push) Successful in 24s
Eine Vorlage allein bringt wenig — sie stellt Fragen, die der Meldende meist
nicht beantworten kann. Deshalb zwei Teile:

diagnose.sh sammelt in einem Zug, was zur Analyse gebraucht wird: Fassungen
aller acht Programme, Betriebssystem, Container ja/nein, Dateisystem des
Repositorys, PostgreSQL-Fassung, Schemastand, Dienstzustand, Gesundheitsbericht
(der auch bei 503 den vollstaendigen Bericht traegt), Bestand, die letzten nicht
erfolgreichen Laeufe mit Fehlercode UND Fehlerklasse, die gemessene
Durchsetzungsstufe und die letzten Fehlerzeilen. Es liest nur.

Geheimnisse kommen nicht hinein, und der Weg dahin ist umgekehrt: Es gibt eine
Liste der Werte, die gezeigt werden duerfen. Eine Sperrliste vergaesse den
naechsten neuen Wert. Zusaetzlich werden die tatsaechlichen Geheimnisse gelesen
und aus JEDER Ausgabe entfernt — auch aus Protokollzeilen, in die sie auf einem
unvorhergesehenen Weg geraten sind. Real geprueft: weder Datenbankpasswort noch
Schluessel noch Administratorpasswort stehen im Bericht.

Die Vorlage beginnt mit sieben Faellen, die wie ein Fehler aussehen und gewolltes
Verhalten sind — "advisory" statt "filesystem", ein Teilfehler, "geloescht aber
nichts frei", 503 mit vollstaendigem Bericht. Das ist keine Abwehr, sondern
spart beiden Seiten einen halben Tag. Pflichtfelder sind Beobachtung, Erwartung,
Schritte, Bereich, Datenrisiko, Haeufigkeit und der Diagnosebericht; Fehlercode
und request_id stehen eigens da, weil sie die beiden wertvollsten Angaben sind.

Beim Erproben zwei Funde:

- Die Installationsanleitung verlangte PostgreSQL 17. setup.sh installiert auf
  Debian 12 aber 15 — und alles lief, bis hin zu einem echten Sicherungslauf.
  Die Anforderung lautet jetzt 15 (geprueft gegen 17 in CI und Entwicklung,
  gegen 15 auf Debian 12), und setup.sh lehnt aeltere Fassungen ab statt sie
  stillschweigend zu nehmen.
- Ein Repository auf der Platte, das nicht in der Control Plane eingetragen ist,
  faellt niemandem auf: Die Sicherung laeuft nie, weil der Server das Ziel nicht
  kennt. Der Bericht benennt diesen Fall jetzt ausdruecklich.

Gegen das echte v1.0.0-rc1-Paket gefahren: Installation, erzeugte Stoerung
(ALL_SOURCES_FAILED / source), Bericht zeigt Code, Klasse, "overlayfs" und
"nie gemessen".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 15:58:00 +02:00
610719c316 Syncova Backups V1
Some checks failed
CI / Backend (Go) (push) Failing after 3m7s
CI / Frontend (React/TypeScript) (push) Successful in 37s
CI / Sicherheitsprüfungen (push) Successful in 44s
Enterprise-Backup-, Recovery-, Verification-, Security- und
Monitoring-Plattform fuer Proxmox VE, Windows, Linux und Dateisysteme.

Der Leitsatz, der fast jede Entscheidung erklaert: Ein Backup gilt erst als
vertrauenswuerdig, wenn Integritaet geprueft und Wiederherstellbarkeit
nachgewiesen wurde. Deshalb steigt ein Wiederherstellungspunkt erst nach einem
tatsaechlich durchgefuehrten Restore-Test auf "recoverable", und Unbekanntes
geht in keine Bewertung als "gut" ein.

Umfang (Phasen 0-23):

- Repository Engine: inhaltsadressierte Bloecke, atomares Commit-Protokoll,
  Katalogaufbau allein aus den Manifesten — ohne Datenbank
- Backup Engine: inhaltsabhaengiges Chunking, Deduplizierung trotz
  Verschluesselung, zstd, AES-256-GCM, Streaming mit Gegendruck
- Agenten fuer Windows und Linux mit Auftragsabholung (Pull-Modell)
- Proxmox-Provider mit beiden Zugriffswegen auf die Sicherungsarchive
- Scheduler, Recovery Engine mit Pruefpunkt, Verification, Unveraenderlichkeit
- Weboberflaeche, Kennzahlen, Meldungen, Berichte, Security Center,
  Ransomware-Heuristik (meldet, handelt nie)
- Disaster Recovery, Haertung, Leistungsmessung, Chaos Testing
- Eingefrorene Vertraege fuer API, Migrationen, Backup-Format und Repository
- Auslieferungspaket fuer linux/amd64, linux/arm64 und windows/amd64

Nicht enthalten und als solches gekennzeichnet: Kapazitaetsprognose, Backup
Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und ACLs.

Gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die
systemd-Einheit und der verpflichtende Proxmox-Meilenstein — ob eine
wiederhergestellte VM startet, ist ungeprueft. Einzelheiten in CHANGELOG.md
und docs/release-candidate.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 09:10:54 +02:00