Die Sicherungsart steht in backup-engine.md, weil dort der Unterschied zwischen
voll und inkrementell erklaert ist — mit der Einordnung, die am haeufigsten
verwechselt wird: Der Platzbedarf steigt bei "immer voll" nicht nennenswert,
die Laufzeit schon.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Abschnitt "Wohin darf zurueckgeschrieben werden?" im Runbook ist der
wichtigste Zusatz: Dass ein Ziel an ProtectSystem=strict scheitert und nicht an
den Rechten des Verzeichnisses, sieht man dem Fehler nicht an. Die Tabelle nennt
die vier Faelle samt Grund.
Die Beispiel-Einheit in der Installationsanleitung fuehrte in denselben Fehler —
sie nannte nur das Repository in ReadWritePaths. Eine Anleitung, deren
Ergebnis keine Wiederherstellung zulaesst, ist schlimmer als keine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs/web-ui.md beschreibt jetzt das Preset samt der drei begruendeten
Abweichungen, die Sitzung mit ihren zwei Uhren und die Fehlergrenze. Dazu zwei
neue Grenzen: Geist Mono wird nicht mitgeliefert, und die Suche im
Ereignisprotokoll filtert weiterhin im Browser.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs/web-ui.md beschrieb die Oberflaeche aus Phase 12 — eine, die es nicht mehr
gibt. Eine Anleitung, die auf Bereiche verweist, die anders heissen und anders
funktionieren, ist schlimmer als keine: Der Leser sucht den Fehler bei sich.
Neu geschrieben.
Eine Aussage darin habe ich beim Nachpruefen korrigiert: `/api/v1/events/stream`
steht zwar in SYNCOVA_API.md, ist aber **auch serverseitig** nicht umgesetzt.
"Nicht angebunden" haette den Mangel der Oberflaeche zugeschoben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Gemeldet wurde ein Abbruch der Einrichtung mit "Der Dienst meldet sich nicht als
betriebsbereit". Der Dienst lief einwandfrei — das Protokoll im Bericht zeigt
einen vollstaendigen Start, und genau fuenfzehn Sekunden spaeter beendet ihn der
Rueckbau. Fuenfzehn Sekunden sind genau fuenfzehn Pruefversuche.
Die Ursache stand ebenfalls im Bericht, eine Zeile weiter oben:
## Gesundheit
curl ist nicht vorhanden.
setup.sh prueft die Betriebsbereitschaft ausschliesslich mit curl. Auf einem
schlanken Serverabbild ist der nicht installiert; das ist der Normalfall und
nicht die Ausnahme. Die Pruefung kam nicht an den Dienst heran, hielt das fuer
einen gescheiterten Start und baute eine funktionierende Anlage zurueck.
Ein Einrichtungsskript darf nicht voraussetzen, was es nicht selbst mitbringt.
Jetzt drei Wege: curl, sonst wget, sonst /dev/tcp der Bash — letzteres gehoert
zur Shell selbst und ist damit ueberall vorhanden. Betrifft setup.sh, update.sh
und diagnose.sh; der Diagnosebericht nennt zusaetzlich, womit er gemessen hat.
Real nachgewiesen auf einem System ohne curl UND ohne wget: rc3 bricht ab, die
korrigierte Fassung laeuft durch. Regressionstest vorhanden und als fangend
geprueft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemeldet wurde ein Abbruch der Einrichtung mit "Der Dienst meldet sich nicht als
betriebsbereit". Der Diagnosebericht enthielt die Ursache woertlich:
syncova-api.service: Failed to set up mount namespacing:
/tmp/syncova-repository: No such file or directory
status=226/NAMESPACE
Die Diensteinheit setzt PrivateTmp=yes. Der Dienst bekommt damit ein eigenes
/tmp, und der in ReadWritePaths genannte Ablageort existiert in seiner Sicht
nicht — systemd bricht ab, bevor das Programm ueberhaupt laeuft.
Der technische Fehler ist der kleinere. Der groessere ist, dass setup.sh einen
Ablageort unter /tmp ueberhaupt angenommen hat: systemd-tmpfiles raeumt dort
regelmaessig auf, und auf einem tmpfs ist nach einem Neustart nichts mehr da.
Ein Backupsystem, das jede Nacht Erfolg meldet und keine Daten hat, ist
schlimmer als gar keines.
Deshalb:
- Fluechtige Ablageorte werden abgelehnt: /tmp, /var/tmp, /dev/shm, /run und
jedes tmpfs oder ramfs. Geprueft wird VOR der Datenbankeinrichtung — ein
unbeaufsichtigter Lauf scheitert damit in Sekunden statt nach Minuten und
einem Rueckbau.
- SYNCOVA_SETUP_ALLOW_VOLATILE_REPOSITORY=ja laesst es ausdruecklich zu; dann
wird PrivateTmp abgeschaltet, sonst startet der Dienst nie. Real geprueft:
Einheit traegt PrivateTmp=no, Dienst laeuft.
- Kommt der Dienst nicht hoch, liefert setup.sh die letzten Journalzeilen gleich
mit und erklaert 226/NAMESPACE. Der Verweis auf journalctl allein war
wertlos: Beim Rueckbau ist der Dienst weg, und der Meldende brauchte einen
zweiten Anlauf, um ueberhaupt zu erfahren, was los war.
Regressionstest vorhanden und als fangend geprueft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Was seit rc1 dazukam und was daran eine Korrektur ist, nicht nur eine Ergaenzung
— PostgreSQL 15 statt 17 und die nicht existierende Umgebungsvariable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Betriebsskripte fuer Linux, im Auslieferungspaket neben den Programmen.
setup.sh richtet eine Anlage vollstaendig ein: PostgreSQL auf Wunsch mit
(apt/dnf/yum/zypper/pacman), Dienstkonto, Verschluesselungsschluessel, Schema,
erster Administrator, gehaertetes Repository, gehaertete systemd-Einheit. Jeder
Schritt vermerkt, was er angelegt hat; bricht der Lauf ab, wird genau das
zurueckgebaut und nichts sonst. Eine bestehende Installation wird nicht
ueberschrieben — dafuer gibt es update.sh, und der Unterschied ist, dass ein
Update vorher sichert.
update.sh haelt die Reihenfolge ein, um die es geht: sichern, anhalten,
tauschen, migrieren, starten, pruefen. Kommt der Dienst danach nicht hoch, holt
es die vorige Fassung zurueck. Ohne pg_dump wird gar nicht erst begonnen — ohne
Sicherung gibt es nach einer misslungenen Migration keinen Weg zurueck.
Repository und Verschluesselungsschluessel bleiben unberuehrt.
uninstall.sh entfernt standardmaessig NUR Dienst und Programme. Datenbank,
Repository und Konfiguration bleiben liegen; jede dieser Loeschungen verlangt
ein woertlich getipptes Bestaetigungswort an einem Terminal. Ein
Deinstallationsskript, das nebenbei die Backups mitnimmt, vernichtet genau das,
wofuer jemand jahrelang Speicher bezahlt hat.
Gegen Debian 12 im Container gefahren — Installation, Anmeldung, Repository
eingetragen, Loeschschutz gemessen (advisory auf overlayfs, richtig), echter
Sicherungslauf, Update mit unveraendertem Bestand, beide Abbauarten.
Drei Fehler dabei gefunden und behoben, alle derselben Art:
- "tr </dev/urandom | head -c 32" und "psql | grep -q": Der frueh geschlossene
Pipe schickt dem Schreiber SIGPIPE, und mit "set -o pipefail" bricht das
Skript mitten in der Einrichtung ab, ohne erkennbaren Grund.
- update.sh las die laufende Fassung mit "grep -o" aus der Antwort von
/health/ready. Die enthaelt gar kein Versionsfeld; grep endet mit 1, und das
Skript nahm ein GELUNGENES Update wieder zurueck — wegen einer Zeile, die nur
der Ausgabe dient.
Dazu: SYNCOVA_ADMIN_PASSWORD stand in der Doku und existiert nicht — das
Passwort kommt ueber die Standardeingabe. Und "syncova-repo break-lock" fehlte
zwar nicht mehr, aber der Test auf die Uebereinstimmung der drei Skripte ist
neu: Drei Skripte, die sich ueber den Installationsort uneinig sind, ergeben
eine Anlage, die sich nicht mehr entfernen laesst.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
