[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!

 

[eehm]

Ich habe nochmals indirekt eine Frage zum Thema Verschlüsselung.
Ich habe mich schon oft damit beschäftigt und am Ende ist immer wieder die Angst da selbst nicht mehr an die Daten zu kommen.
Jetzt habe ich mal eine generelle Frage.

Nehmen wir als Szenario an:
Pool mit RAIDZ1 aus 3 x 8TB HDD unverschlüsselt.
Hierbei packe ich nach dem offline setzten des Pools die Festpatten an verschiedene Orte:
z.B. Gartenhaus, Garage und Nachbar

Vorrausgesetzt, dass ein möglicher Angreifer überhaupt weiß mit einem ZFS Pool umzugehen.
Wie wahrscheinlich ist es, dass er aus einer der drei Festplatte "brauchbare" Daten wiederherstellen kann?

 

[asm@s24]

Genau so, wie wenn zwei Deiner Disks kaputt wären: null.

 

[gea]

Wie wahrscheinlich ist es, dass er aus einer der drei Festplatte "brauchbare" Daten wiederherstellen kann?

Um die Daten zu lesen werden zwei der drei Platten benötigt. Bei einer Platte kann man allenfalls statistisch "raten"

Vereinfachtes Beispiel
Es wird der Name "Bruce Willis" gespeichert. Auf der einen Platte steht Bruce auf der anderen Willis. Hat jemand nur eine Platte und kennt den Context der Daten (US Schauspieler), so kann er den den Namen mit einer gewissen Wahrscheinlichkeit erraten oder eingrenzen. Bei normalen Daten gibts keine Option der Wiederherstellung.

 

[Fischje]

Highlights from yesterday's OpenZFS developer conference:

Most important OpenZFS announcement: AnyRaid
This is a new vdev type based on mirror or Raid-Zn to build a vdev from disks of any size where datablocks are striped in tiles (1/64 of smallest disk or 16G). Largest disk can be 1024x of smallest with maximum of 256 disks per vdev. AnyRaid Vdevs can expand, shrink and auto rebalance on shrink or expand.

Basically the way Raid-Z should have be from the beginning and propably the most superiour flexible raid concept on the market.
...

Hat da jemand schon Erfahrungen gemacht?

 

[gea]

AnyRaid ist wohl frühestens in OpenZFS 2.5 enthalten, aktuell ist 2.3 und für 2.4 gibt es einen Release Candidate.

 

[Fischje]

Ich gehe davon aus, dass du uns auf dem laufenden hälst, @gea

Derweilen versuch ich mich nach langem hin und her mal an deinem aio-proxmox-napp-it, weil ich den filer nicht mehr als vm/ct laufen lassen möchte.
Lediglich das wöchentliche Backup, was ich bisher mit PBS gemacht habe, muss ich dann ja anders lösen - oder?