-
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