-
jf released this
2026-08-18 15:48:06 +00:00 | 0 commits to main since this releaseSicherungsart je Auftrag
Bisher entschied die Anlage allein: Liegt ein Elternbackup vor, wird inkrementell gesichert. Jetzt wählbar —
Einstellung Wirkung Inkrementell Erster Lauf voll, danach nur Geändertes. Standard Immer voll Jeder Lauf liest die gesamte Quelle Fester Volltag Inkrementell, zusätzlich an einem Wochentag voll — etwa „immer freitags" Der Platzbedarf steigt bei „immer voll" nicht nennenswert — unveränderte Blöcke werden dedupliziert und liegen weiterhin nur einmal im Repository. Was steigt, ist die Laufzeit: Jeder Lauf liest, hasht, komprimiert und verschlüsselt alles neu. Das steht so in der Maske, weil es die häufigste Verwechslung ist.
Der Wochentag wird in der Zeitzone des Zeitplans bestimmt. Rechnete der Server in UTC, bekäme ein Betreiber in Berlin seine Vollsicherung am Donnerstagabend und wunderte sich, warum sie freitags fehlt. Vier Tests halten das fest, der entscheidende durch Mutation als fangend bestätigt.
Migration
000014mit drei CHECKs. Der dritte lehnt „immer voll" zusammen mit einem Wochentag ab: Dann ist ohnehin jeder Lauf voll. Die Regel steht in der Datenbank, weil im Code jede Stelle sie einhalten müsste — eine vergisst es.Behoben
Das Aufnahme-Token eines Agenten zeigte „undefined". Das Feld heißt
token, nichtenrollment_token— Letzteres ist der Name im Anfragekörper der Registrierung.Das war der dritte Formfehler dieser Art (nach
/retention-policiesund dem Integritätslauf). Alle konsumierten Endpunkte sind jetzt gegen den laufenden Dienst abgeglichen, statt aus der Struktur abgeleitet.Aufnahmedialog mit Anleitung
Vollständige Anleitung für Linux und Windows, umschaltbar, mit fertig ausgefüllten Befehlen — Serveradresse und Token bereits eingesetzt, jeder Schritt einzeln kopierbar. Eine Anleitung mit Platzhaltern führt zuverlässig dazu, dass jemand
<token>wörtlich einsetzt und dann eine Fehlermeldung sucht, die nichts mit seinem Problem zu tun hat.Linux: Paket, Dienstkonto, Aufnahme, systemd-Einheit. Windows: PowerShell mit
New-Service— mit dem Hinweis, dass der Windows-Dienst nie auf echter Hardware lief.Dazu die beiden Stolperstellen:
--stateerwartet eine Datei, kein Verzeichnis (mit einem Verzeichnis hält sich der Agent für registriert und läuft ohne Token), und der Agent braucht Schreibzugriff auf das Repository.update.sh rüstet die Wiederherstellungsfläche nach
Sie kam mit rc8 dazu; eine Anlage aus einer älteren Fassung hat sie nicht. Ohne sie scheitert jede Wiederherstellung an
ProtectSystem=strict.update.shlegt/srv/syncova-restorejetzt an und trägt es inReadWritePathsein. Der Schritt aus den rc8-Notizen entfällt damit — ein Schritt, den man von Hand ausführen muss, wird übersehen und fällt erst im Ernstfall auf.Aktualisieren
sudo /opt/syncova/update.shMigration
000014wird dabei angewandt. Bestehende Aufträge bleiben unverändert: Ohne Angabe giltincremental— das bisherige Verhalten.
Unverändert offen: Windows-Dienst, systemd-Einheit des Agenten und der Proxmox-Bootmeilenstein sind gebaut, aber nie auf echter Hardware gefahren.
Downloads
-
2026-08-18 13:55:52 +00:00 | 2 commits to main since this releaseWiederherstellung von Dateien und Ordnern mit Auswahl statt Textfeld — und die Erklärung, warum vorher gar keine Wiederherstellung funktionierte.
Warum keine Wiederherstellung ging
Nicht die Rechte des Zielverzeichnisses, sondern die Härtung des Dienstes: Er läuft mit
ProtectSystem=strictundReadWritePathsnur auf Repository und Sicherungsordner. Jedes Ziel außerhalb endete mitmkdir: permission denied— und zwar nach der Vorabprüfung, an der unangenehmsten Stelle./tmpscheiterte anders: MitPrivateTmp=yeshat der Dienst ein eigenes/tmp. Was dort landet, ist von außen unsichtbar.Ort Ergebnis /srv/syncova-restore✓ von setup.shangelegt und eingetragenweitere aus --wiederherstellungsziel✓ /tmp/…✗ privater Namensraum, von außen unsichtbar /etc,/usr,/var/lib,/root…✗ vom Zielschutz gesperrt alles andere ✗ schreibgeschützt durch ProtectSystem=strictDer Ort liegt unter
/srv, weil/var/libauf der Sperrliste des Zielschutzes steht — beide Regeln zugleich zu erfüllen lässt genau/srvübrig.Auswahl statt Textfeld
- Ordnerbaum für das Ziel. Er meldet je Verzeichnis, ob der Dienst dort schreiben darf — gemessen durch eine Probedatei, nicht aus den Rechtebits abgeleitet. Unter
ProtectSystem=strictsagen die Bits nichts über den Namensraum aus. Gesperrte Orte werden gezeigt, nicht versteckt: Sonst bliebe offen, warum ein Pfad fehlt. - Browser für den Backup-Inhalt. Ordner und einzelne Dateien lassen sich zurückholen. Der Baum entsteht aus den Pfaden, nicht aus Verzeichniseinträgen — ein Manifest kann eine Datei enthalten, deren Elternordner nicht als eigener Eintrag vorliegt, und wer nur
directory-Einträge auflistet, verliert ganze Teilbäume.
Zwei neue Endpunkte, der eingefrorene Vertrag ist entsprechend erweitert:
GET /filesystem/browseundGET /backups/{id}/contents.Behoben
„can't access property toLocaleString, chunks_checked is undefined" beim Integritätslauf. Die Ergebnisse liegen unter
details, und die Felder heißenmissing_chunks/corrupted_chunks, nicht umgekehrt. Betrifft alle vier Prüfendpunkte — sie tragen dieselbe Hülle.Derselbe Fehler wie zuvor bei
/retention-policies: die Antwortform angenommen statt geprüft. Alle konsumierten Endpunkte sind jetzt gegen den laufenden Dienst abgeglichen.Geist Mono liegt im Paket
Drei Schnitte, 128 KB, OFL-Lizenz dabei. Ausgeliefert vom eigenen Ursprung — das verlangt die CSP, und ein Backup-Server, dessen Oberfläche von der Erreichbarkeit eines CDN abhängt, wäre auch ohne CSP falsch.
font-display: swap, damit der Text sofort steht.Nachgewiesen
Gegen Debian 12 mit echtem PostgreSQL und nginx: Vollwiederherstellung (5 Dateien), nur ein Ordner (2 Dateien), nur eine Datei (1 Datei) — alle drei bitgenau. Der Server nennt
/srv/syncova-restoreals beschreibbar und/etc,/usr,/varals gesperrt.Aktualisieren
sudo /opt/syncova/update.shBei einer bestehenden Installation fehlt die Wiederherstellungsfläche, weil sie erst
setup.shanlegt. Nachholen:sudo install -d -m 0750 -o syncova -g syncova /srv/syncova-restore sudo systemctl edit syncova-api # ReadWritePaths= um /srv/syncova-restore ergänzen sudo systemctl restart syncova-apiBekannte Grenze
Eine Auswahl je Lauf, kein Mehrfachhaken. Eine Liste ausgewählter Pfade kennt die API nicht; mehrere Läufe hintereinander ergäben mehrere Ausgänge, und ein „teilweise fehlgeschlagen" ließe sich dann nicht mehr erklären.
Unverändert offen: Windows-Dienst, systemd-Einheit des Agenten und der Proxmox-Bootmeilenstein sind gebaut, aber nie auf echter Hardware gefahren.
Downloads
- Ordnerbaum für das Ziel. Er meldet je Verzeichnis, ob der Dienst dort schreiben darf — gemessen durch eine Probedatei, nicht aus den Rechtebits abgeleitet. Unter
-
2026-08-18 13:10:17 +00:00 | 4 commits to main since this releaseBehebt einen Absturz, macht die Sitzung brauchbar und stellt das Aussehen um.
Behoben
/retentionzeigte einen schwarzen Bildschirm.GET /retention-policiesliefert ein Objekt{policies, predefined}— als einziger von zehn geprüften Listenendpunkten. Die Oberfläche behandelte es als Array;mapgibt es auf einem Objekt nicht, React hängte den ganzen Baum aus. Der Regressionstest füttert jetzt die echte Antwortform; ein Test mit einem Array hätte den Fehler nie gefunden, und genau das war passiert.- Jedes Neuladen führte zurück zur Anmeldung. Die Tokens lagen nur im Arbeitsspeicher.
- Ein Fehler in einer Komponente schwärzte die ganze Konsole. Jetzt sitzt eine Fehlergrenze um den Seiteninhalt: Menü und Kopfzeile bleiben stehen, der Fehlertext ist lesbar und kopierbar.
Sitzung
Sie überlebt ein Neuladen und endet nach 30 Minuten — gerechnet als frühere von zwei Grenzen:
Harte Obergrenze 30 Minuten ab Anmeldung, durch keine Interaktion verschiebbar Untätigkeitsgrenze 30 Minuten ohne Eingabe Die verbleibende Zeit läuft neben „Abmelden" und wird unter fünf Minuten auffällig.
Dass die Tokens überhaupt abgelegt werden, kehrt eine frühere Entscheidung um. Was den Rest trägt, ist nicht der Speicherort (
sessionStorage, stirbt mit dem Tab), sondern der sofortige serverseitige Widerruf: Die Tokens sind opak, kein JWT, und genau dafür wurden sie gewählt.Sechs Tests halten die Grenzen fest, zwei davon durch Mutation als fangend bestätigt: Wer beim Vermerken einer Interaktion die Obergrenze mitverschiebt, macht aus „30 Minuten" ein „unbegrenzt, solange die Maus wackelt".
Aussehen
Farben, Radien, Schatten und Schrift aus dem Preset
b5vnF8SMi: violett als Handlungsfarbe, Radius 0, schattenlos, durchgehend Geist Mono.Drei begründete Abweichungen:
- Die Statusfarben bleiben. Das Preset kennt nur
destructiveund fünf Diagrammfarben; ohne die fünf Bedeutungen ließe sich ein Teilfehler nicht von einem Erfolg unterscheiden — die eine Aussage, auf die es in dieser Konsole ankommt. - Das dunkle Thema hängt an
[data-theme='dark'], nicht an.dark..darkfunktioniert zusätzlich. - Geist Mono lädt nicht nach. Sie steht zuerst im Stapel; liegt sie nicht auf dem Gerät, greift die System-Monospace. Eine Schrift von einem fremden Host zu holen verbietet die CSP — und ein Backup-Server, der für seine Oberfläche ins Internet greift, wäre auch ohne CSP falsch.
Dazu Umlaute auf allen Seiten (vorher durchgehend ae/oe/ue/ss), 33 Erläuterungen von Absätzen auf einen Satz gekürzt und neue Module: acht Schnellzugriffe auf der Übersicht sowie sechs mitgelieferte Aufbewahrungsvorlagen als Kacheln — die lieferte der Server schon immer mit, die Oberfläche warf sie bisher weg.
Nachgewiesen
Gegen Debian 12 mit echtem PostgreSQL und nginx: alle 18 Seiten liefern 200, das ausgelieferte CSS trägt Akzent, Radius 0 und Geist Mono,
/retentionzeigt 0 eigene Regeln und 6 anklickbare Vorlagen.84 Tests grün,
tscsauber,eslintohne Warnung. CSS 28,7 KB.Aktualisieren
sudo /opt/syncova/update.shSichert zuerst Datenbank und Konfiguration, tauscht dann die Programme. Kommt der Dienst nicht hoch, holt es die vorige Fassung zurück. Repository und Verschlüsselungsschlüssel werden nie angefasst.
Unverändert offen: Windows-Dienst, systemd-Einheit des Agenten und der Proxmox-Bootmeilenstein sind gebaut, aber nie auf echter Hardware gefahren. Geist Mono wird nicht mitgeliefert; ohne die Schrift auf dem Gerät greift die System-Monospace.
Downloads
-
2026-08-18 12:05:15 +00:00 | 8 commits to main since this releaseDie Weboberfläche ist eine vollständige Verwaltungskonsole geworden.
Vorher erreichte sie 23 von 95 fachlichen Endpunkten; schreibend waren es neun, vier davon An- und Abmeldung. Real verwaltbar war: einen Auftrag anlegen, einen Bericht erzeugen, eine Meldung bestätigen. Das war ein Leseinstrument mit Assistent, keine Konsole.
Jetzt sind es 89 von 95.
Neu bedienbar
- Wiederherstellung als vierstufiger Assistent — vorher nur über
curl. Die Vorabprüfung ist ein eigener Schritt, weil sie den Unterschied zwischen Hoffnung und Nachweis macht: Sie schreibt nichts und stellt fest, ob jeder benötigte Block noch da ist. Ein Manifest allein belegt nur, dass jemand einmal etwas gesichert hat. - Wiederherstellungspunkte mit Bewertung, Legal Hold, Fristverlängerung, Löschung und Ransomware-Einschätzung.
- Prüfung mit allen fünf Prüfarten. Zustand und Ergebnis stehen nebeneinander: Eine gescheiterte Prüfung ist kein Befund am Backup.
- Repositories mit Integritätslauf, Katalog-Neuaufbau, Gesundheitsprüfung und gemessener Durchsetzungsstufe.
- Aufbewahrung mit Regeln und Vorschau vor dem Löschen.
- Proxmox — neun Endpunkte, die vorher gar keine Oberfläche hatten — und Agenten samt einmaliger Anzeige des Aufnahme-Tokens.
- Benutzer, Rollen, Benachrichtigungswege, eigener zweiter Faktor.
Neues Design
Tailwind v4 und Radix-Primitive nach shadcn-Muster, alles gebündelt (keine externen Ressourcen — die CSP lässt sie ohnehin nicht zu). Dark Mode, einklappbare Seitenleiste, Bedienung auf Tablets. Achtzehn Seiten in fünf Bereichen.
Die tragende Entscheidung ist keine Frage des Aussehens: Die Zuordnung der Fachbegriffe auf die fünf Statusfarben liegt an genau einer Stelle. Verteilt über die Seiten erschiene früher oder später irgendwo
partial_failuregrün — und ein Betreiber hält einen Teilfehler dann für einen Erfolg. Ein unbekannter Serverzustand wird neutral dargestellt, niemals grün.Die drei Hürden vor dem Überschreiben
Der Wiederherstellungs-Assistent setzt sie sichtbar um: das Kennzeichen, die eigene Berechtigung
restores.overwrite(nicht inrestores.executeenthalten) und der wörtlich wiederholte Zielpfad. Läuft die dritte ins Leere, weil das Ziel leer ist, entfällt sie — ein Ritual ohne Anlass gewöhnt das Wegklicken an.Funde beim Nachweis
- Die Einstufung heißt
successful, nichtunverified. Das ist die gefährlichste Stelle der Oberfläche:successfulbedeutet „der Lauf ist durchgelaufen" — nicht „wiederherstellbar". Es ist deshalb neutral, nicht grün. Regressionstest, durch Mutation als fangend bestätigt. describeApiErrorwarf die genauere Servermeldung weg. EinSERVICE_UNAVAILABLEmit „Für diesen Bericht ist keine Sicherheitsprüfung eingerichtet" wurde zu „Der Dienst ist derzeit nicht vollständig verfügbar" — der Betreiber hätte den Fehler bei seiner Anlage gesucht statt bei der Einrichtung dieses einen Berichts. Jetzt hat die Servermeldung Vorrang.- Einem Fehler nach einer Handlung fehlte
role="alert". Ein Screenreader hätte ihn nicht angesagt. - Der Geheimnis-Scanner griff korrekt beim Platzhaltertext des SSH-Schlüsselfelds. Gekennzeichnet, statt das Muster aufzuweichen.
Aufgeräumt
Ein Stylesheet statt sieben; das ausgelieferte CSS fällt von 54 auf 30 KB. Entfernt, weil ersetzt:
JobsPanel,StatusIndicator,PageState.Nachgewiesen
Gegen Debian 12 mit echtem PostgreSQL und nginx, über genau die Aufrufe, die die Konsole macht: Repository übernommen, Durchsetzungsstufe gemessen (
advisory— auf overlayfs richtig), Auftrag angelegt, Lauf 202, zweiter Anstoß 409, Sicherung erfolgreich (3.000.006 Byte, 0 übergangen), Blockprüfungclean, Vorabprüfung „wiederherstellbar: 2 Dateien, 2,9 MiB", Wiederherstellung nach/etcabgewiesen. Alle 18 Seiten liefern über HTTPS 200.76 Tests grün,
tscsauber,eslintohne Warnung.Aktualisieren
sudo /opt/syncova/update.shEs sichert zuerst Datenbank und Konfiguration, hält den Dienst an, tauscht die Programme, migriert und startet. Kommt der Dienst nicht hoch, holt es die vorige Fassung zurück. Repository und Verschlüsselungsschlüssel werden nie angefasst.
Unverändert offen: Windows-Dienst, systemd-Einheit des Agenten und der Proxmox-Bootmeilenstein sind gebaut, aber nie auf echter Hardware gefahren. Dazu ohne Oberfläche: sechs Detail-Endpunkte (ihre Daten stehen in den Listen), Live-Fortschritt (
/api/v1/events/streamist auch serverseitig nicht umgesetzt) und der Simple Mode.Downloads
- Wiederherstellung als vierstufiger Assistent — vorher nur über
-
2026-08-18 06:53:20 +00:00 | 12 commits to main since this releaseDie Oberfläche richtet sich jetzt mit ein.
Bisher endete
setup.shmit einer laufenden API auf127.0.0.1:8080und der Aufgabe, einen Webserver von Hand davorzusetzen — der häufigste Punkt, an dem eine Einrichtung liegen blieb.Neu
setup.shrichtet nginx und ein selbst signiertes Zertifikat ein. Es gilt für den Rechnernamen, den vollständigen Namen und jede globale IPv4-Adresse des Servers (subjectAltName— moderne Browser lesen denCNnicht 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:8080gebunden. 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.
ufwundfirewalldwerden 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. Geprüft wird mit
nginx -t, bevor die Konfiguration übernommen wird; hält sie nicht, wird sie entfernt, der Grund genannt und der Nachholweg gezeigt.
Auf einer bestehenden Anlage nachholen
sudo /opt/syncova/setup.sh --weboberflaecheAuslassen:
--ohne-weboberflaeche.Port 443 geben Sie selbst frei — das nimmt Ihnen die Einrichtung bewusst nicht ab:
sudo ufw allow 443/tcp # ufw sudo firewall-cmd --permanent --add-service=https # firewalld sudo firewall-cmd --reloadZwei Funde beim Erproben
http2 on;gibt es erst ab nginx 1.25.1. Debian 12 liefert 1.22, wo HTTP/2 ein Parameter vonlistenist. Die neue Schreibweise ergibt dort „unknown directive http2", und nginx startet nicht. Die Fassung wird jetzt gelesen.setup.shkopierte nurdiagnose.shneben die Programme. Der eigene Hinweis „Später nachholen:/opt/syncova/setup.sh" verwies damit auf eine Datei, die es nicht gab. Schwerer wiegtuninstall.sh: Wer das ausgepackte Paket aufräumte, hätte die Anlage nie wieder entfernen können. Jetzt kommen alle vier Skripte mit.
Nachgewiesen
Im Container gegen Debian 12 mit nginx 1.22: Neuinstallation von Grund auf, Oberfläche und
/api/von außen über HTTPS erreichbar (200), SPA-Fallback trägt, Anmeldung und Repository-Anlage durch nginx hindurch, Durchsetzungsstufe gemessen, HTTP leitet mit 301 auf HTTPS, Fingerabdruck stimmt mit dem genannten überein, Neuausstellung des Zertifikats geprüft.Regressionstests für beide Funde, beide durch Mutation als fangend bestätigt.
Selbst signiertes Zertifikat
Es schützt gegen Mitlesen, nicht gegen einen Mittelsmann — niemand bestätigt, dass es zu diesem Server gehört. Vergleichen Sie den Fingerabdruck beim ersten Aufruf; danach ist die Browserwarnung unbedenklich. Für den Dauerbetrieb gehört ein Zertifikat einer Zertifizierungsstelle nach
/etc/syncova/tls/.
Unverändert offen: Windows-Dienst, systemd-Einheit des Agenten und der Proxmox-Meilenstein sind gebaut, aber nie auf echter Hardware gefahren. Siehe
docs/release-candidate.md.Downloads
-
Syncova Backups V1 — Release Candidate 4
Pre-Release2026-08-18 06:22:47 +00:00 | 13 commits to main since this releaseVierter Auslieferungskandidat. Er behebt #2 — die Einrichtung brach ab, obwohl der Dienst einwandfrei lief.
Was passiert war
setup.shprüfte die Betriebsbereitschaft ausschließlich mitcurl. Auf einem schlanken Serverabbild ist der nicht installiert — das ist der Normalfall, nicht die Ausnahme.Die Prüfung kam nicht an den Dienst heran, hielt das für einen gescheiterten Start und baute eine funktionierende Anlage zurück.
Im Protokoll des Meldenden stand der Beleg: Der Dienst startete vollständig, und genau fünfzehn Sekunden später beendete ihn der Rückbau — fünfzehn Sekunden sind fünfzehn Prüfversuche.
Behoben
Die Prüfung nimmt jetzt
curl, sonstwget, sonst/dev/tcpder Bash. Das letzte gehört zur Shell selbst und ist damit überall vorhanden.Ein Einrichtungsskript darf nicht voraussetzen, was es nicht selbst mitbringt.
Betrifft
setup.sh,update.shunddiagnose.sh. Der Diagnosebericht nennt jetzt zusätzlich, womit er gemessen hat:Abgefragt mit: Bash /dev/tcp (weder curl noch wget vorhanden)Real nachgewiesen auf einem System ohne
curlund ohnewget: rc3 bricht ab, rc4 läuft durch. Regressionstest vorhanden und als fangend geprüft.Aktualisieren
tar -xzf syncova-v1.0.0-rc4-linux-amd64.tar.gz cd syncova-v1.0.0-rc4-linux-amd64 shasum -a 256 -c SHA256SUMS sudo ./setup.sh # Neuinstallation sudo ./update.sh # aus rc1, rc2 oder rc3Unverändert: warum RC und nicht 1.0.0
Drei Zusagen sind gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die systemd-Einheit des Agenten und der Proxmox-Meilenstein — ob eine wiederhergestellte VM startet, ist ungeprüft.
CHANGELOG.md·docs/release-candidate.mdDownloads
-
Syncova Backups V1 — Release Candidate 3
Pre-Release2026-08-17 14:14:41 +00:00 | 14 commits to main since this releaseDritter Auslieferungskandidat. Er behebt #1 — die Einrichtung brach ab, wenn das Repository unter
/tmpliegen sollte.Was passiert war
Die Diensteinheit setzt
PrivateTmp=yes. Der Dienst bekommt damit ein eigenes/tmp; der inReadWritePathsgenannte Ablageort existiert in seiner Sicht nicht, und systemd bricht ab, bevor das Programm überhaupt läuft:syncova-api.service: Failed to set up mount namespacing: /tmp/syncova-repository: No such file or directory status=226/NAMESPACEWas daran der größere Fehler war
Nicht der Startfehler, sondern dass
setup.sheinen Ablageort unter/tmpüberhaupt angenommen hat.systemd-tmpfilesräumt dort regelmäßig auf, und auf einem tmpfs ist nach einem Neustart nichts mehr da. Die Sicherungen wären von selbst verschwunden — ohne Meldung, bis jemand sie braucht.Ein Backupsystem, das jede Nacht Erfolg meldet und keine Daten hat, ist schlimmer als gar keines.
Behoben
- Flüchtige Ablageorte werden abgelehnt:
/tmp,/var/tmp,/dev/shm,/runund jedes tmpfs oder ramfs. Geprüft wird vor der Datenbankeinrichtung — ein unbeaufsichtigter Lauf scheitert damit in Sekunden statt nach Minuten und einem Rückbau. - Ausdrückliche Freigabe für Wegwerf-Umgebungen:
SYNCOVA_SETUP_ALLOW_VOLATILE_REPOSITORY=ja. Dann wirdPrivateTmpabgeschaltet, sonst startete der Dienst nie. - Der Abbruch zeigt den Grund. Kommt der Dienst nicht hoch, liefert
setup.shdie letzten Journalzeilen gleich mit und erklärt226/NAMESPACE. Der bloße Verweis aufjournalctlwar wertlos: Beim Rückbau ist der Dienst weg.
Regressionstest vorhanden und als fangend geprüft.
Aktualisieren
Betrifft nur die Einrichtung; eine laufende Anlage ist nicht betroffen.
tar -xzf syncova-v1.0.0-rc3-linux-amd64.tar.gz cd syncova-v1.0.0-rc3-linux-amd64 shasum -a 256 -c SHA256SUMS sudo ./update.sh # aus rc1 oder rc2 sudo ./setup.sh # NeuinstallationUnverändert: warum RC und nicht 1.0.0
Drei Zusagen sind gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die systemd-Einheit des Agenten und der Proxmox-Meilenstein — ob eine wiederhergestellte VM startet, ist ungeprüft.
Vollständige Liste:
CHANGELOG.md·docs/release-candidate.mdDownloads
- Flüchtige Ablageorte werden abgelehnt:
-
Syncova Backups V1 — Release Candidate 2
Pre-Release2026-08-17 14:00:53 +00:00 | 15 commits to main since this releaseZweiter Auslieferungskandidat von Syncova Backups V1.
rc1bleibt abrufbar, ist aber überholt. Wer neu installiert, nimmt diese Fassung.Neu gegenüber rc1
diagnose.shliegt jetzt im Paket und wird vonsetup.shundupdate.shnach/opt/syncova/diagnose.shgelegt.sudo /opt/syncova/diagnose.shEs sammelt in einem Zug, was für eine Fehlersuche gebraucht wird: Fassungen aller Programme, Betriebssystem, Container ja/nein, Dateisystem des Repositorys, PostgreSQL-Fassung, Schemastand, Dienstzustand, Gesundheitsbericht, Bestand, die letzten nicht erfolgreichen Läufe mit Fehlercode und Fehlerklasse, die gemessene Durchsetzungsstufe und die letzten Fehlerzeilen.
Es liest nur und verändert nichts. Geheimnisse entfernt es selbsttätig — über eine Erlaubnisliste, nicht über eine Sperrliste: Ein künftiger neuer Wert fällt damit von selbst heraus.
Dazu eine Fehlervorlage unter
.gitea/ISSUE_TEMPLATE/. Sie beginnt mit sieben Fällen, die wie ein Fehler aussehen und gewolltes Verhalten sind — das spart beiden Seiten Zeit.Zwei Korrekturen
Beide beim Erproben gefunden, beide betreffen die Anleitung und nicht die Software:
- PostgreSQL 15 genügt. Die Installationsanleitung verlangte 17. Debian 12 liefert 15, und darauf läuft 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 — Aufrufparameter stünden in der Prozessliste.
Unverändert: warum RC und nicht 1.0.0
Drei Zusagen sind vollständig gebaut, aber nie auf echter Hardware gefahren:
- Der Windows-Dienst. Übersetzt für Windows,
vet-sauber, nie geladen. - Die systemd-Einheit des Agenten. Inhaltlich korrigiert, nie geladen.
- Proxmox. Entdecken, Sichern, Prüfen und bitgenaues Zurückschreiben laufen durch — gegen einen Nachbau der API. Ob eine wiederhergestellte VM startet, ist ungeprüft.
Installation
tar -xzf syncova-v1.0.0-rc2-linux-amd64.tar.gz cd syncova-v1.0.0-rc2-linux-amd64 shasum -a 256 -c SHA256SUMS sudo ./setup.shAktualisieren aus rc1:
sudo ./update.shaus dem neuen Paket. Es sichert vorher Datenbank und Konfiguration und holt die vorige Fassung zurück, wenn der Dienst danach nicht hochkommt.Skript Wofür setup.shVollständige Einrichtung; baut bei Abbruch zurück, was dieser Lauf angelegt hat update.shSichert zuerst; Rückweg bei Fehlschlag uninstall.shEntfernt standardmäßig nur Dienst und Programme diagnose.shZustandsbericht für eine Fehlermeldung docs/installation.md·docs/recovery-runbook.md·docs/troubleshooting.md·docs/release-howto.mdNicht enthalten
Kapazitätsprognose, Backup Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und POSIX-ACLs, harte Verknüpfungen. VMware, Hyper-V, Kubernetes, M365 und Object Storage sind nicht Teil dieser Fassung.
Pakete
Paket Inhalt linux-amd64,linux-arm64Server, Oberfläche, Agent, alle Werkzeuge, vier Betriebsskripte windows-amd64Agent und syncova-repoStatisch gebunden (
CGO_ENABLED=0); geprüft in einem leerendebian:12-slim. Prüfsummen liegen im Paket und zusätzlich alsSHA256SUMSdaneben.Downloads
- PostgreSQL 15 genügt. Die Installationsanleitung verlangte 17. Debian 12 liefert 15, und darauf läuft alles bis zum echten Sicherungslauf.
-
Syncova Backups V1 — Release Candidate 1
Pre-Release2026-08-17 13:36:53 +00:00 | 17 commits to main since this releaseErster Auslieferungskandidat von Syncova Backups V1.
Alle 24 Phasen des Umsetzungsplans sind gebaut. 32 von 38 Zeilen der Akzeptanzmatrix sind gefahren — abgehakt ist nur, was tatsächlich ausgeführt wurde.
Warum RC und nicht 1.0.0
Drei Zusagen sind vollständig gebaut, aber nie auf echter Hardware gefahren:
- Der Windows-Dienst. Er übersetzt für Windows und ist
vet-sauber, wurde aber nie geladen. Kommandozeilenweg und Auftragsausführung sind plattformunabhängig nachgewiesen. - Die systemd-Einheit des Agenten. 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 VM startet, ist ungeprüft.
Solange das offen ist, wäre eine
1.0.0eine Zusage, die diese Punkte nicht deckt.Installation
tar -xzf syncova-v1.0.0-rc1-linux-amd64.tar.gz cd syncova-v1.0.0-rc1-linux-amd64 shasum -a 256 -c SHA256SUMS sudo ./setup.shDas Paket bringt drei Betriebsskripte mit:
setup.shVollständige Einrichtung. Bricht ein Schritt ab, wird zurückgebaut, was dieser Lauf angelegt hat update.shSichert zuerst Datenbank und Konfiguration; holt die vorige Fassung zurück, wenn der Dienst nicht hochkommt uninstall.shEntfernt standardmäßig nur Dienst und Programme. Datenbank, Repository und Konfiguration bleiben liegen Ausführlich:
docs/installation.md· Im Ernstfall:docs/recovery-runbook.md· Bei Störungen:docs/troubleshooting.mdDer Schritt, den die meisten auslassen
Erst ein durchgeführter Wiederherstellungstest hebt einen Punkt auf
recoverable. Alles davor ist ein Indiz, kein Nachweis —docs/release-howto.mdführt in vier Stufen durch die Prüfung einer frischen Anlage.Nicht enthalten
Kapazitätsprognose, Backup Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und POSIX-ACLs, harte Verknüpfungen (der Inhalt kommt zurück, die Verknüpfung nicht). VMware, Hyper-V, Kubernetes, M365 und Object Storage sind nicht Teil dieser Fassung.
Eingefrorene Verträge
API (102 Endpunkte), Migrationen, Backup-Format und Repository-Protokoll sind ab dieser Fassung festgeschrieben. Jede Abweichung schlägt in einer Prüfung an.
Pakete
Paket Inhalt linux-amd64,linux-arm64Server, Oberfläche, Agent, alle Werkzeuge, Betriebsskripte windows-amd64Agent und syncova-repoStatisch gebunden (
CGO_ENABLED=0); geprüft in einem leerendebian:12-slim. Prüfsummen liegen im Paket und zusätzlich alsSHA256SUMSdaneben.Einzelheiten:
CHANGELOG.md·docs/release-candidate.mdDownloads
- Der Windows-Dienst. Er übersetzt für Windows und ist