[Sammelthread] ZFS Stammtisch

[eehm]

ZFS Datasets (ZFS Dateisysteme, ZFS zvols und ZFS Snaps) können nicht per SMB gelöscht werden.

Danke du hast recht, das war vorhin wohl ein Anzeigefehler.
Das Dataset bleibt auch nach dem "Löschen" erhalten. Allerdings ist der Inhalt des Datasets per SMB als Admin löschbar und bei einer Neuausführung des Replication Task werden die Daten nicht wieder hergesetllt.
Also sind nicht per SMB sichtbar.
Sie sind aber im ZFS System vorhanden und auch per Rollback wieder herstellbar (dann auch wieder per SMB sichtbar).
Ist das erklärbar, dass ich den Inhalt eines Datasets per SMB löschen (nicht wirklich gelöscht, aber per Windows SMB-Freigabe nicht mehr zu sehen) kann oder ist das eigentlich auch nicht möglich?

Klar ich kann das natürlich umgehen indem ich das Dataset nach der Replizierung auf Read-only lasse oder dem SMB-User nur Leserechte einräume. Aber ich würde das Verhalten gerne verstehen, weil es mich verwundert!

 

[eehm]

Ich habe jetzt weiter getestet.
Ergebnis ist folgendes:

Fall 1: Startpunkt
Replizierung von x Snapshots vom Master zum Backup.
Dann löschen von Dateien in einem Dataset.
Ergebnis:
Daten sind per SMB nicht mehr sichtbar.
Test:
Erneute Replizierung von x Snapshots vom Master zum Backup. (selber Task)
Ergebnis nach Test
Daten sind per SMB nicht mehr sichtbar. (wären aber per ZFS über ein Rollback wieder herzustellen.

Fall 2: Neuer Snapshot kommt hinzu
Replizierung von x+1 Snapshots vom Master zum Backup. (
Ergebnis:
Zuvor gelöschte Daten sind per SMB wieder sichtbar.

 

[gea]

mögliche Ursachen
Wenn man auf dem Zieldateisystem auch nur ein Byte ändert, scheitert die darauf folgende Replikation es sei denn man macht vor dem receive ein rollback mit zfs receive -F

Man muss recursive arbeiten (zfs send -r) damit sub-datasets übertragen werden

theoretisch
mit ABE (smb share parameter) kann man die Anzeige von Dateien/Ordnern unterdrücken auf die man keine Rechte hat

 

[eehm]

mögliche Ursachen
Wenn man auf dem Zieldateisystem auch nur ein Byte ändert, scheitert die darauf folgende Replikation es sei denn man macht vor dem receive ein rollback mit zfs receive -F

Danke, das ist dann sicher die Ursache.

Ich mache jetzt einfach immer auf dem Backup-System beim Replizieren ein SET read-only, dann komme ich nicht mehr in die Versuchung hier etwas zu probieren oder SCHLIMMER aus versehen zu Verändern oder gar dort zu speichern und die Daten dann am Ende verlieren.
Vom Backup will ich so und so nur im schlimmsten Fall etwas lesen.

 

[gea]

üblich ist rollback vor Replikation mit zfs receive -F

 

[eehm]

üblich ist rollback vor Replikation mit zfs receive -F

OK, danke.
Da muss ich mal schauen, ob ich das in meinen TrueNAS Scale Task irgendwie eingebaut bekomme!