Jerrit Fritzsche
a37631c501
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>
6.5 KiB
Änderungen
V1 — Release Candidate 3, 17. August 2026
Behebt Issue #1: Die
Einrichtung brach ab, wenn das Repository unter /tmp liegen sollte.
- Ein flüchtiger Ablageort wird abgelehnt —
/tmp,/var/tmp,/dev/shm,/runund jedes tmpfs.systemd-tmpfilesrä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 weichtPrivateTmp, sonst könnte der Dienst nicht starten. - Der Abbruch zeigt jetzt den Grund. Kommt der Dienst nicht hoch, liefert
setup.shdie letzten Journalzeilen gleich mit und erklärt226/NAMESPACE. Vorher verwies er nur aufjournalctl— und beim Rückbau war der Dienst dann schon weg.
V1 — Release Candidate 2, 17. August 2026
Ergänzt gegenüber rc1:
diagnose.shliegt jetzt im Paket und wird vonsetup.shundupdate.shnach/opt/syncova/diagnose.shgelegt. 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.shprüft die vorgefundene Fassung jetzt und lehnt ältere als 15 ab, statt sie stillschweigend zu nehmen. SYNCOVA_ADMIN_PASSWORDgibt 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.shrichtet 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.shsichert 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.shentfernt 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
fsyncden 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.