bashclub/zsync
Watch
1
0
Fork
You've already forked zsync
 0
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions

Snapshots eines Deltas mit zfs hold schützen #36

Closed
thorsten.spille wants to merge 0 commits from thorsten.spille/feature-6-holds into main AGit
pull from: thorsten.spille/feature-6-holds
merge into: bashclub:main
Conversation 1 Commits - Files changed -
thorsten.spille commented 2026-10-15 22:38:21 +02:00
Owner
Copy link

Setzt #6 um.

Befund (Test-VM, echtes ZFS)

ZFS schützt nur den Snapshot, der gerade gesendet wird. Während send s1 → s2:

Snapshot löschbar?
s2 (wird gesendet) nein, „dataset is busy“
s1 (Basis) ja
s3 (soll als Nächstes gesendet werden) ja → nächstes Delta scheitert

Änderung

  • neue Einstellung source_hold (bestehende Configs ohne Eintrag: 0, Template und Beispiel: 1)
  • vor dem Transfer eines Datasets: zfs hold auf Basis und alle noch zu sendenden Snapshots (bei der Erstreplikation auf deren Snapshot), Tag pro Backupserver und Ziel wie beim Bookmark
  • Freigabe vor dem Löschen auf dem Ziel und per Exit-Handler (trap, auch bei Fehlern); ein Hold aus einem abgebrochenen Lauf existiert schon, wird beim Halten ignoriert und am Ende mit freigegeben
  • finish_status läuft jetzt aus einem gemeinsamen Exit-Handler
  • README („Holds on the source“, mit Befehlen zum manuellen Freigeben), DOCUMENTATION_DE, Beispiel-Config, CHANGELOG

Tests

  • Integration hold: während eines gedrosselten Deltas sind Basis und geplanter Snapshot nicht löschbar, danach keine Holds, Hold eines abgebrochenen Laufs wird freigegeben
  • Stub: Szenario 26 (hold/release um die Übertragung); alle 25 übrigen identisch zu main

Closes #6

🤖 Generated with Claude Code

Setzt #6 um. ## Befund (Test-VM, echtes ZFS) ZFS schützt nur den Snapshot, der gerade gesendet wird. Während `send s1 → s2`: | Snapshot | löschbar? | |---|---| | `s2` (wird gesendet) | nein, „dataset is busy“ | | `s1` (Basis) | **ja** | | `s3` (soll als Nächstes gesendet werden) | **ja** → nächstes Delta scheitert | ## Änderung - neue Einstellung `source_hold` (bestehende Configs ohne Eintrag: `0`, Template und Beispiel: `1`) - vor dem Transfer eines Datasets: `zfs hold` auf Basis und alle noch zu sendenden Snapshots (bei der Erstreplikation auf deren Snapshot), Tag pro Backupserver und Ziel wie beim Bookmark - Freigabe vor dem Löschen auf dem Ziel und per Exit-Handler (`trap`, auch bei Fehlern); ein Hold aus einem abgebrochenen Lauf existiert schon, wird beim Halten ignoriert und am Ende mit freigegeben - `finish_status` läuft jetzt aus einem gemeinsamen Exit-Handler - README („Holds on the source“, mit Befehlen zum manuellen Freigeben), DOCUMENTATION_DE, Beispiel-Config, CHANGELOG ## Tests - Integration `hold`: während eines gedrosselten Deltas sind Basis und geplanter Snapshot nicht löschbar, danach keine Holds, Hold eines abgebrochenen Laufs wird freigegeben - Stub: Szenario 26 (hold/release um die Übertragung); alle 25 übrigen identisch zu `main` Closes #6 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Hold the snapshots of a dataset on the source while it is replicated
All checks were successful
/ build (pull_request) Successful in 25s
Details
/ test (debian-13) (pull_request) Successful in 43s
Details
/ test (ubuntu-24.04) (pull_request) Successful in 43s
Details
/ test (ubuntu-26.04) (pull_request) Successful in 50s
Details
/ test (debian-12) (pull_request) Successful in 50s
Details
/ integration (pull_request) Successful in 1m18s
Details
/ publish (pull_request) Has been skipped
Details
/ package (pull_request) Successful in 0s
Details
72a291ed2a 
ZFS itself only protects the snapshot that is being sent (dataset is busy).
Checked on the test VM: during "send s1 -> s2" the base s1 and the next
snapshot s3 could be destroyed, so the next delta would fail.

New setting source_hold (existing configurations without it: 0, new
configurations and the example: 1): before the transfer of a dataset the base
and all snapshots still to be sent (and the snapshot of an initial replication)
get a hold with the tag per backup host and target; they are released before
the deletion on the target and on exit (trap, also on errors). A hold left over
by a killed run already exists, is ignored when holding and released at the end.
finish_status runs from a common exit handler now.

Tests: integration case hold (base and planned snapshot cannot be destroyed
during a throttled delta, no holds afterwards, stale hold released); stub
scenario 26; all other scenarios identical to main.

Refs #6

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
thorsten.spille commented 2026-10-15 22:41:43 +02:00
Author
Owner
Copy link

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

Manuell nach `main` gemergt (e86d076), CI inkl. publish nach testing grün. Schließe den PR.
thorsten.spille closed this pull request 2026-10-15 22:41:43 +02:00
All checks were successful
/ build (pull_request) Successful in 25s
Details
/ test (debian-13) (pull_request) Successful in 43s
Details
/ test (ubuntu-24.04) (pull_request) Successful in 43s
Details
/ test (ubuntu-26.04) (pull_request) Successful in 50s
Details
/ test (debian-12) (pull_request) Successful in 50s
Details
/ integration (pull_request) Successful in 1m18s
Details
/ publish (pull_request) Has been skipped
Details
/ package (pull_request) Successful in 0s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug

   
enhancement
No labels
bug
enhancement
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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!36
No description provided.