syncova-backup/CHANGELOG.md
Jerrit Fritzsche b6668c600d
Some checks failed
CI / Backend (Go) (push) Failing after 29s
CI / Frontend (React/TypeScript) (push) Successful in 33s
CI / Sicherheitsprüfungen (push) Successful in 24s
Weboberflaeche richtet sich mit ein (rc5)
Bisher endete setup.sh mit einer laufenden API auf 127.0.0.1:8080 und der
Aufgabe, einen Webserver von Hand davorzusetzen. Das war der haeufigste Punkt,
an dem eine Einrichtung liegen blieb.

setup.sh richtet jetzt nginx ein und stellt ein selbst signiertes Zertifikat
aus. Es gilt fuer Rechnernamen, vollstaendigen Namen und jede globale
IPv4-Adresse (subjectAltName — moderne Browser lesen den CN nicht mehr), 3650
Tage; der SHA-256-Fingerabdruck wird genannt.

Drei Entscheidungen:

- Die API bleibt an 127.0.0.1:8080 gebunden. Sie auf alle Schnittstellen zu
  legen waere der kuerzere Weg und der falsche: Die Verschluesselung liesse
  sich dann umgehen, indem man Port 8080 direkt anspricht.
- Die Firewall wird gemeldet, nicht geaendert. Eine Einrichtung, die
  selbsttaetig einen Port ins Netz oeffnet, hebelt genau die Entscheidung aus,
  fuer die jemand die Firewall aufgesetzt hat.
- Scheitert die Oberflaeche, scheitert nicht die Einrichtung. Geprueft wird mit
  nginx -t, bevor die Konfiguration uebernommen wird; haelt sie nicht, wird sie
  entfernt und der Nachholweg gezeigt.

Zwei Funde beim Erproben:

- http2 on; gibt es erst ab nginx 1.25.1. Debian 12 liefert 1.22, wo HTTP/2 ein
  Parameter von listen ist — die neue Schreibweise ergibt dort "unknown
  directive http2", und nginx startet nicht. Die Fassung wird jetzt gelesen.
- setup.sh kopierte nur diagnose.sh neben die Programme. Der eigene Hinweis
  "Spaeter nachholen: /opt/syncova/setup.sh --weboberflaeche" verwies damit auf
  eine Datei, die es nicht gab; schwerer wiegt uninstall.sh — wer das
  ausgepackte Paket aufraeumte, haette die Anlage nie wieder entfernen koennen.
  Jetzt kommen alle vier Skripte mit.

Nachgewiesen im Container gegen Debian 12 mit nginx 1.22: Neuinstallation von
Grund auf, Oberflaeche und /api/ von aussen ueber HTTPS erreichbar (200),
SPA-Fallback traegt, Anmeldung und Repository-Anlage durch nginx hindurch,
Durchsetzungsstufe gemessen, HTTP leitet mit 301 auf HTTPS, Fingerabdruck
stimmt mit dem genannten ueberein, Neuausstellung des Zertifikats geprueft.

Regressionstests fuer beide Funde, beide durch Mutation als fangend bestaetigt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 08:53:15 +02:00

186 lines
9.1 KiB
Markdown

# Änderungen
## V1 — Release Candidate 5, 18. August 2026
Die Oberfläche richtet sich jetzt mit ein. Bisher endete `setup.sh` mit einer
laufenden API auf `127.0.0.1:8080` und der Aufgabe, einen Webserver von Hand
davorzusetzen — der häufigste Punkt, an dem eine Einrichtung liegen blieb.
- **`setup.sh` richtet nginx und ein selbst signiertes Zertifikat ein.** Das
Zertifikat gilt für den Rechnernamen, den vollständigen Namen und **jede**
globale IPv4-Adresse des Servers (`subjectAltName` — moderne Browser lesen
den `CN` nicht mehr), 3650 Tage. Der SHA-256-Fingerabdruck wird genannt, damit
er sich beim ersten Aufruf im Browser vergleichen lässt.
- **Die API bleibt an `127.0.0.1:8080` gebunden.** Erreichbar ist sie nur durch
nginx hindurch. Sie stattdessen auf alle Schnittstellen zu legen wäre der
kürzere Weg und der falsche: Die Verschlüsselung ließe sich dann umgehen,
indem man Port 8080 direkt anspricht.
- **Die Firewall wird gemeldet, nicht geändert.** `ufw` und `firewalld` werden
erkannt und ihr Zustand ausgegeben; geöffnet wird nichts. Eine Einrichtung,
die selbsttätig einen Port ins Netz öffnet, hebelt genau die Entscheidung aus,
für die jemand die Firewall aufgesetzt hat.
- **Scheitert die Oberfläche, scheitert nicht die Einrichtung.** Die
Konfiguration wird mit `nginx -t` geprüft, **bevor** sie übernommen wird; hält
sie nicht, wird sie entfernt, der Grund genannt und der Nachholweg gezeigt.
Die Anlage läuft in jedem Fall.
- **Nachträglich einrichten:** `sudo /opt/syncova/setup.sh --weboberflaeche`.
Auslassen: `--ohne-weboberflaeche`.
Ein Fund beim Erproben:
- **`http2 on;` gibt es erst ab nginx 1.25.1.** Debian 12 liefert 1.22, wo
HTTP/2 ein Parameter von `listen` ist. Die neue Schreibweise ergibt dort
„unknown directive http2", und nginx startet nicht. Die Fassung wird jetzt
gelesen und die passende Schreibweise erzeugt.
## V1 — Release Candidate 4, 18. August 2026
Behebt [Issue #2](https://git.jfritzsche.de/jf/syncova-backup/issues/2): Die
Einrichtung brach mit „Der Dienst meldet sich nicht als betriebsbereit" ab,
obwohl der Dienst einwandfrei lief.
- **Die Bereitschaftsprüfung hängt nicht mehr an `curl`.** Sie weicht auf `wget`
aus und zuletzt auf die Bash selbst (`/dev/tcp`), die überall vorhanden ist.
Auf einem schlanken Serverabbild ist `curl` nicht installiert — das ist der
Normalfall, nicht die Ausnahme. Ein Einrichtungsskript darf nicht
voraussetzen, was es nicht selbst mitbringt.
- Betrifft `setup.sh`, `update.sh` und `diagnose.sh`. Der Diagnosebericht nennt
jetzt zusätzlich, **womit** er gemessen hat.
## V1 — Release Candidate 3, 17. August 2026
Behebt [Issue #1](https://git.jfritzsche.de/jf/syncova-backup/issues/1): Die
Einrichtung brach ab, wenn das Repository unter `/tmp` liegen sollte.
- **Ein flüchtiger Ablageort wird abgelehnt** — `/tmp`, `/var/tmp`, `/dev/shm`,
`/run` und jedes tmpfs. `systemd-tmpfiles` räumt dort auf, ein tmpfs ist nach
einem Neustart leer: Die Sicherungen verschwänden von selbst, ohne Meldung,
bis jemand sie braucht. Geprüft wird **vor** der Datenbankeinrichtung, damit
ein unbeaufsichtigter Lauf in Sekunden scheitert statt nach Minuten.
Für Wegwerf-Umgebungen: `SYNCOVA_SETUP_ALLOW_VOLATILE_REPOSITORY=ja` — dann
weicht `PrivateTmp`, sonst könnte der Dienst nicht starten.
- **Der Abbruch zeigt jetzt den Grund.** Kommt der Dienst nicht hoch, liefert
`setup.sh` die letzten Journalzeilen gleich mit und erklärt `226/NAMESPACE`.
Vorher verwies er nur auf `journalctl` — und beim Rückbau war der Dienst dann
schon weg.
## 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.