Zustand pro Dataset im Monitoring: verwaist, Kette gerissen, Kette in Gefahr #21

New issue

Closed

opened 2026-10-15 19:25:29 +02:00 by thorsten.spille · 0 comments

thorsten.spille commented

2026-10-15 19:25:29 +02:00

Owner

Heute kennt das Monitoring (#15) nur „letzter Lauf fehlgeschlagen, n von m Datasets“. Ein Dataset, das sich nie mehr von selbst erholt, sieht genauso aus wie ein einmaliger Fehler.

Fälle beim Anfügen

Fall	Lage	Heute
A normal	neuester Ziel-Snapshot (GUID) ist auf der Quelle	Delta
B auseinandergelaufen	neuester Ziel-Snapshot fehlt auf der Quelle, ein älterer ist noch da (Rollback/Löschen)	`[ERROR] No matching snapshot …` (#5)
C Kette gerissen	kein Ziel-Snapshot existiert mehr auf der Quelle	dieselbe Meldung wie B
D Ziel leer	Ziel-Dataset ohne Snapshots	`[ERROR] No snapshot found on …`
E verwaist	Ziel ohne Quelle (gelöscht/umbenannt) bzw. Quelle vorhanden, aber nicht mehr ausgewählt (Tag entfernt, received)	nichts

C mit Ursache: Rotation durchgelaufen (neuester Ziel-Snapshot älter als der älteste der Quelle) oder Dataset auf der Quelle neu angelegt (creation der Quelle nach dem neuesten Ziel-Snapshot).

Umsetzung

zsync schreibt pro Dataset einen Zustand: /var/lib/bashclub-zsync/<config>.datasets (Dataset, Zustand, seit, Detail).
E: nach der Replikationsschleife lokal zfs list -H -o name,used -r $target gegen die vorhandene Liste aller Quell-Datasets (auch nicht ausgewählte, damit Zwischenebenen nicht als verwaist gelten); nur auswerten, wenn die Abfrage der Quelle erfolgreich war. Quittieren per User-Property am Ziel: zfs set bashclub:zsync-orphan=keep <dataset>. Kein automatisches Löschen.
Frühwarnung „Kette in Gefahr“: Basis-Snapshot ist auf der Quelle schon der älteste seiner Rotation (die nächste Rotation reißt die Kette), bzw. ein Dataset schlägt seit X fehl und die Aufbewahrung der Quelle reicht nur Y.
Log mit kopierbarer Behebung, z. B. für C: zfs rename <ziel> <ziel>.broken-<datum> (alter Stand bleibt als Archiv, der nächste Lauf repliziert neu).

Monitoring (#15)

C/D: CRIT „no common snapshot with the source, full replication needed“ mit Ursache
Kette in Gefahr: WARN
B: WARN (bzw. was #5 daraus macht)
E: WARN (kein CRIT, nur Platz), optional mit Karenzzeit, quittierte nur als Hinweis

Offen

Überschneidung mit checkzfs prüfen (meldet es Replikate ohne Quelle schon?)
optional später: Umbenennung erkennen (GUID des neuesten verwaisten Snapshots auf einem anderen Quell-Dataset)

Rahmen: Default = bisheriges Verhalten, der Replikations-/Löschalgorithmus bleibt unverändert. Eigener Branch/PR mit Test. Teil von 2.0.0, Reihenfolge siehe Roadmap #16.

Heute kennt das Monitoring (#15) nur „letzter Lauf fehlgeschlagen, n von m Datasets“. Ein Dataset, das sich nie mehr von selbst erholt, sieht genauso aus wie ein einmaliger Fehler. ## Fälle beim Anfügen | Fall | Lage | Heute | |---|---|---| | A normal | neuester Ziel-Snapshot (GUID) ist auf der Quelle | Delta | | B auseinandergelaufen | neuester Ziel-Snapshot fehlt auf der Quelle, ein älterer ist noch da (Rollback/Löschen) | `[ERROR] No matching snapshot …` (#5) | | C Kette gerissen | kein Ziel-Snapshot existiert mehr auf der Quelle | dieselbe Meldung wie B | | D Ziel leer | Ziel-Dataset ohne Snapshots | `[ERROR] No snapshot found on …` | | E verwaist | Ziel ohne Quelle (gelöscht/umbenannt) bzw. Quelle vorhanden, aber nicht mehr ausgewählt (Tag entfernt, received) | nichts | C mit Ursache: **Rotation durchgelaufen** (neuester Ziel-Snapshot älter als der älteste der Quelle) oder **Dataset auf der Quelle neu angelegt** (`creation` der Quelle nach dem neuesten Ziel-Snapshot). ## Umsetzung - zsync schreibt pro Dataset einen Zustand: `/var/lib/bashclub-zsync/<config>.datasets` (Dataset, Zustand, seit, Detail). - **E**: nach der Replikationsschleife lokal `zfs list -H -o name,used -r $target` gegen die vorhandene Liste aller Quell-Datasets (auch nicht ausgewählte, damit Zwischenebenen nicht als verwaist gelten); nur auswerten, wenn die Abfrage der Quelle erfolgreich war. Quittieren per User-Property am Ziel: `zfs set bashclub:zsync-orphan=keep <dataset>`. Kein automatisches Löschen. - **Frühwarnung „Kette in Gefahr“**: Basis-Snapshot ist auf der Quelle schon der älteste seiner Rotation (die nächste Rotation reißt die Kette), bzw. ein Dataset schlägt seit X fehl und die Aufbewahrung der Quelle reicht nur Y. - Log mit kopierbarer Behebung, z. B. für C: `zfs rename <ziel> <ziel>.broken-<datum>` (alter Stand bleibt als Archiv, der nächste Lauf repliziert neu). ## Monitoring (#15) - C/D: **CRIT** „no common snapshot with the source, full replication needed“ mit Ursache - Kette in Gefahr: **WARN** - B: **WARN** (bzw. was #5 daraus macht) - E: **WARN** (kein CRIT, nur Platz), optional mit Karenzzeit, quittierte nur als Hinweis ## Offen - Überschneidung mit checkzfs prüfen (meldet es Replikate ohne Quelle schon?) - optional später: Umbenennung erkennen (GUID des neuesten verwaisten Snapshots auf einem anderen Quell-Dataset) --- **Rahmen:** Default = bisheriges Verhalten, der Replikations-/Löschalgorithmus bleibt unverändert. Eigener Branch/PR mit Test. Teil von 2.0.0, Reihenfolge siehe Roadmap #16.

thorsten.spille added this to the 2.0.0 milestone

2026-10-15 19:25:29 +02:00

thorsten.spille added the

enhancement

label

2026-10-15 19:25:29 +02:00

thorsten.spille referenced this issue

2026-10-15 19:25:29 +02:00

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

thorsten.spille referenced this issue

2026-10-15 19:25:30 +02:00

Ziel nach Rollback auf der Quelle optional zurückrollen #5