syncova-backup/CHANGELOG.md

# Änderungen

## V1 — Release Candidate 2, 17. August 2026

Ergänzt gegenüber `rc1`:

- **`diagnose.sh`** liegt jetzt im Paket und wird von `setup.sh` und `update.sh`
  nach `/opt/syncova/diagnose.sh` gelegt. Es sammelt in einem Zug, was für eine
  Fehlersuche gebraucht wird — Fassungen, Dateisystem des Repositorys,
  Schemastand, letzte nicht erfolgreiche Läufe mit Fehlercode und Fehlerklasse,
  gemessene Durchsetzungsstufe. Es liest nur und entfernt Geheimnisse aus jeder
  Ausgabe.
- **Fehlervorlage** unter `.gitea/ISSUE_TEMPLATE/`.

Zwei Korrekturen, beide beim Erproben gefunden:

- **PostgreSQL 15 genügt.** Die Anleitung verlangte 17; Debian 12 liefert 15,
  und darauf lief alles bis zum echten Sicherungslauf. `setup.sh` prüft die
  vorgefundene Fassung jetzt und lehnt ältere als 15 ab, statt sie
  stillschweigend zu nehmen.
- **`SYNCOVA_ADMIN_PASSWORD` gibt es nicht.** Die Anleitung nannte diese
  Umgebungsvariable; das Passwort kommt über die Standardeingabe. Korrigiert.

`rc1` bleibt abrufbar, ist aber überholt.

## V1 — 14. August 2026

Die erste Fassung. Sie sichert Dateisysteme unter Linux und Windows sowie
Gäste eines Proxmox-VE-Verbunds, prüft die Wiederherstellbarkeit und weist sie
nach.

### Was sie kann

**Sichern und Wiederherstellen.** Inhaltsabhängige Blockfindung, Deduplizierung
auch über verschlüsselte Bestände hinweg, zstd, AES-256-GCM, Streaming-Pipeline
mit Gegendruck. Zusatzsicherungen tragen ein vollständiges Manifest — ein
Restore liest genau eine Datei, es gibt keine Kette aufzulösen. Wiederherstellung
mit Vorabprüfung, Prüfpunkt und Fortsetzung nach Abbruch.

**Ein Repository, das ohne die Anlage auskommt.** Inhaltsadressierte Blöcke,
atomares Commit-Protokoll, Katalogaufbau allein aus den Manifesten. Fällt der
Control-Server samt Datenbank aus, lässt sich beides aus dem Repository
zurückholen.

**Vertrauen wird nachgewiesen, nicht behauptet.** Fünf Prüfarten bis zum
tatsächlichen Wiederherstellungstest, eine Einstufung, die nur mit
durchgeführtem Test auf `recoverable` steigt, und eine Bewertung, in die
Unbekanntes niemals als gut eingeht.

**Löschschutz mit gemessener Durchsetzungsstufe.** Was das Betriebssystem
nachweislich verhindert, wird gemeldet — nicht, was die Einstellung verspricht.
Dazu Legal Hold, Fristverlängerung ohne Verkürzungsmöglichkeit und
Aufbewahrungsregeln.

**Oberfläche, Kennzahlen, Meldungen, Berichte, Security Center** und eine
Ransomware-Heuristik, die meldet und niemals selbst handelt.

### Was sie ausdrücklich nicht kann

- **Kapazitätsprognose.** Die Kennzahl erscheint mit Begründung statt mit einer
  Null.
- **Kopie an einen zweiten Ort (Backup Copy).** Nicht umgesetzt; das Security
  Center führt den Bereich als ungeprüft und rechnet ihn nicht ein.
- **Changed Block Tracking bei Proxmox.** Proxmox gibt geänderte Blöcke nicht
  über die REST-API heraus. Eine Zusatzsicherung eines Gasts spart deshalb
  Platz, aber keine Lesezeit.
- **Erweiterte Attribute, POSIX-ACLs und SELinux-Kontexte.** Gehen bei einer
  Sicherung verloren.
- **Harte Verknüpfungen** werden aufgelöst: Der Inhalt kommt vollständig
  zurück, die Verknüpfung nicht.
- **VMware, Hyper-V, Kubernetes, M365, Object Storage, Synthetic Full.** Nicht
  Teil dieser Fassung.

### Was gebaut, aber nicht auf echter Hardware gefahren wurde

Diese Punkte sind vollständig umgesetzt und gegen Nachbauten geprüft. Was fehlt,
ist die Ausführung auf der jeweiligen Plattform — und bis dahin gelten sie
nicht als freigegeben:

- **Der Windows-Dienst.** Er übersetzt für Windows und ist `vet`-sauber, wurde
  aber nie geladen. Der Kommandozeilenweg und die gesamte Auftragsausführung
  sind plattformunabhängig nachgewiesen.
- **Die systemd-Einheit.** Inhaltlich korrigiert, nie auf einem Linux-System
  geladen.
- **Proxmox.** Entdecken, Sichern, Prüfen und bitgenaues Zurückschreiben laufen
  durch — gegen einen Nachbau der API. **Ob eine wiederhergestellte Maschine
  startet, ist ungeprüft.**
- **Der SSH-Zugriffsweg auf Proxmox-Knoten.** Die Fingerabdruckprüfung ist
  getestet, eine echte Verbindung gab es nie.

### Einrichtung, Aktualisierung, Entfernung

Das Linux-Paket bringt drei Skripte mit:

- **`setup.sh`** richtet eine Anlage vollständig ein — PostgreSQL auf Wunsch
  mit, Dienstkonto, Schlüssel, Schema, erster Administrator, gehärtetes
  Repository, systemd-Einheit. Bricht ein Schritt ab, wird zurückgebaut, was
  dieser Lauf angelegt hat; Vorgefundenes bleibt unangetastet.
- **`update.sh`** sichert **zuerst** Datenbank und Konfiguration, hält den
  Dienst an, tauscht die Programme, migriert mit der neuen Fassung und startet.
  Kommt der Dienst danach nicht hoch, holt es die vorige Fassung zurück.
  Repository und Verschlüsselungsschlüssel werden nie angefasst.
- **`uninstall.sh`** entfernt standardmäßig **nur** Dienst und Programme.
  Datenbank, Repository und Konfiguration bleiben liegen; jede dieser drei
  Löschungen verlangt ein wörtlich getipptes Bestätigungswort an einem
  Terminal.

### Eingefrorene Verträge

Ab dieser Fassung sind API (102 Endpunkte), Migrationen, Backup-Format und
Repository-Protokoll festgeschrieben. Jede Abweichung schlägt in einer Prüfung
an; Einzelheiten in `docs/release-candidate.md`.

### Bekannte Grenzen

- Das Manifest liegt vollständig im Speicher — rund 200 Byte je Blockverweis,
  also etwa 1,5 GiB bei 10 TB Quelldaten.
- Bei vielen kleinen Dateien begrenzt `fsync` den Durchsatz auf rund 100 Dateien
  je Sekunde. Das ist der Preis des Commit-Protokolls und kein Fehler.
- Weitergeleitete IP-Header werden ignoriert; hinter einem Reverse Proxy steht
  im Auditprotokoll dessen Adresse.