Bookmarks als Anfügepunkt, damit eine durchgelaufene Rotation die Kette nicht reißt #35

Closed
thorsten.spille wants to merge 0 commits from thorsten.spille/feature-22-bookmarks into main AGit

Setzt #22 um.

Problem

Steht die Replikation länger, als die Quelle ihre Snapshots aufbewahrt, löscht die Rotation den Snapshot, mit dem das Replikat endet. Dann hilft nur eine neue Vollreplikation (seit #21 als broken gemeldet).

Vorab mit echtem ZFS geprüft (Test-VM, ZFS 2.3.9)

  • zfs send -i pool/ds#bookmark pool/ds@neu funktioniert unverschlüsselt und raw-verschlüsselt (-w), auch nachdem der Snapshot des Bookmarks gelöscht ist
  • Rollback über das Bookmark hinaus: zfs rollback -r löscht neuere Bookmarks mit; ZFS lehnt den Send danach ab („incremental source does not exist“). Ein Replikat kann also nie an eine andere Historie angefügt werden.

Änderung

  • neue Einstellung source_bookmark (bestehende Configs ohne Eintrag: 0, Template und Beispiel: 1)
  • nach erfolgreicher Replikation eines Datasets: Bookmark des neuesten replizierten Snapshots auf der Quelle, Name pro Backupserver und Ziel #zsync_<host>_<ziel>; nur ersetzt, wenn es woanders hinzeigt
  • fehlt der neueste Ziel-Snapshot auf der Quelle, aber das Bookmark hat seine guid: erstes Delta aus dem Bookmark, die weiteren wie gewohnt; Log continuing from the bookmark …
  • Bookmark lässt sich nicht anlegen (z. B. altes Pool-Feature): [WARN], Replikation läuft weiter
  • greift nur dort, wo zsync bisher mit „No matching snapshot“ aufgab; der normale Ablauf ist unverändert
  • README („Bookmarks on the source“), DOCUMENTATION_DE, Beispiel-Config, CHANGELOG

Tests

  • Integration: neuer Fall bookmark (unverschlüsselt + verschlüsselt: Rotation löscht alle Ziel-Snapshots auf der Quelle → Anfügen aus dem Bookmark, Bookmark weitergesetzt, Zustand ok); der Fall rollback läuft mit Bookmarks und bleibt diverged
  • Stub: Szenarien 24 (Bookmark setzen) und 25 (aus Bookmark anfügen); alle 23 übrigen identisch zu main

Closes #22

🤖 Generated with Claude Code

Setzt #22 um. ## Problem Steht die Replikation länger, als die Quelle ihre Snapshots aufbewahrt, löscht die Rotation den Snapshot, mit dem das Replikat endet. Dann hilft nur eine neue Vollreplikation (seit #21 als `broken` gemeldet). ## Vorab mit echtem ZFS geprüft (Test-VM, ZFS 2.3.9) - `zfs send -i pool/ds#bookmark pool/ds@neu` funktioniert unverschlüsselt **und raw-verschlüsselt** (`-w`), auch nachdem der Snapshot des Bookmarks gelöscht ist - **Rollback über das Bookmark hinaus:** `zfs rollback -r` löscht neuere Bookmarks mit; ZFS lehnt den Send danach ab („incremental source does not exist“). Ein Replikat kann also nie an eine andere Historie angefügt werden. ## Änderung - neue Einstellung `source_bookmark` (bestehende Configs ohne Eintrag: `0`, Template und Beispiel: `1`) - nach erfolgreicher Replikation eines Datasets: Bookmark des neuesten replizierten Snapshots auf der Quelle, Name pro Backupserver und Ziel `#zsync_<host>_<ziel>`; nur ersetzt, wenn es woanders hinzeigt - fehlt der neueste Ziel-Snapshot auf der Quelle, aber das Bookmark hat seine guid: erstes Delta aus dem Bookmark, die weiteren wie gewohnt; Log `continuing from the bookmark …` - Bookmark lässt sich nicht anlegen (z. B. altes Pool-Feature): `[WARN]`, Replikation läuft weiter - greift nur dort, wo zsync bisher mit „No matching snapshot“ aufgab; der normale Ablauf ist unverändert - README („Bookmarks on the source“), DOCUMENTATION_DE, Beispiel-Config, CHANGELOG ## Tests - Integration: neuer Fall `bookmark` (unverschlüsselt + verschlüsselt: Rotation löscht alle Ziel-Snapshots auf der Quelle → Anfügen aus dem Bookmark, Bookmark weitergesetzt, Zustand ok); der Fall `rollback` läuft mit Bookmarks und bleibt `diverged` - Stub: Szenarien 24 (Bookmark setzen) und 25 (aus Bookmark anfügen); alle 23 übrigen identisch zu `main` Closes #22 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Continue from a bookmark if the rotation deleted the base snapshot
All checks were successful
/ build (pull_request) Successful in 27s
/ integration (pull_request) Successful in 1m6s
/ test (debian-13) (pull_request) Successful in 46s
/ test (ubuntu-24.04) (pull_request) Successful in 46s
/ test (ubuntu-26.04) (pull_request) Successful in 51s
/ test (debian-12) (pull_request) Successful in 52s
/ publish (pull_request) Has been skipped
/ package (pull_request) Successful in 0s
a8d970b18f
If the replication stopped longer than the source keeps its snapshots, no
common snapshot remained and only a full replication helped.

New setting source_bookmark (existing configurations without it: 0, new
configurations and the example: 1): after a successful replication of a
dataset a bookmark of the newest replicated snapshot is kept on the source,
named per backup host and target (#zsync_<host>_<target>) and only replaced if
it points elsewhere. If the newest target snapshot no longer exists on the
source but the bookmark has its guid, the first delta is sent from the bookmark
(zfs send -i pool/ds#bm), the following ones as usual.

Checked with real ZFS: sends from bookmarks work unencrypted and raw encrypted;
zfs rollback -r destroys newer bookmarks, so after a rollback on the source the
bookmark does not exist and the dataset stays "diverged" (target_rollback).

Tests: integration case bookmark (plain and encrypted), the rollback case runs
with bookmarks; stub scenarios 24/25; all other scenarios identical to main.

Refs #22

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Author
Owner

Manuell nach main gemergt (54560e4), CI inkl. publish nach testing grün. Schließe den PR.

Manuell nach `main` gemergt (54560e4), CI inkl. publish nach testing grün. Schließe den PR.
thorsten.spille closed this pull request 2026-10-15 22:28:05 +02:00
All checks were successful
/ build (pull_request) Successful in 27s
/ integration (pull_request) Successful in 1m6s
/ test (debian-13) (pull_request) Successful in 46s
/ test (ubuntu-24.04) (pull_request) Successful in 46s
/ test (ubuntu-26.04) (pull_request) Successful in 51s
/ test (debian-12) (pull_request) Successful in 52s
/ publish (pull_request) Has been skipped
/ package (pull_request) Successful in 0s

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
bug
enhancement
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
bashclub/zsync!35
No description provided.