Datensicherheit von ZFS "aushebeln"

[Canyon!]

Hi,

ich habe ein TrueNAS im Einsatz wo ich das Hauptaugenmerk auf Datensicherheit lege. (RAIDZ2/3 usw.)
Um die Sicherheitsfeatures von ZFS aufrecht zu erhalten, darf ich Dateien ja eigentlich nur auf dem NAS direkt bearbeiten (z.B. via NFS/SMB), oder?

Wenn ich eine Datei vom NAS auf meinen PC (ohne ZFS) kopiere, dort ne Woche liegen lasse, bearbeite und anschließend wieder aufs NAS schiebe und die vorhandene Datei überschreibe,
dann profitiere ich von ZFS in diesem Fall ja gar nicht. Wäre ja möglich dass die Datei während sie auf meinem PC war einen Fehler abbekommen hat o.Ä.

Ich habe überlegt Synchting einzurichten und die Projekte an denen ich aktuell arbeite auf die jeweiligen Clients zu syncen.
Die Ordner lokal zu haben ist doch einfacher und schneller, als über das NAS zu arbeiten. Vor allem wenn man unterwegs ist und über VPN auf den Share zugreift.

Auf den Clients habe ich weder ZFS noch ECC.
ZFS eignet sicher der Logik nach also mehr zur Archivierung als aktiv darauf zu arbeiten?

Außerdem:
Wenn ich zwei Shares auf einem Client gemountet habe und eine Datei von dem einen Share auf den anderen verschiebe.
Wie verhält es sich da? Da können mögliche Dateifehler die währen dem Vorgang passieren auch nicht durch ZFS erfasst werden, oder?
Der Zeit nach zu urteilen wie lange dieser Vorgang braucht, geht die Datei erst über das Netzwerk zum Client und von der wieder auf den anderen Share.
Das halte ich für ziemlich sinnlos... gibt es keine Möglichkeit die Datei quasi direkt auf dem NAS zu verschieben? Das würde doch viel schneller gehen, oder?

Ich weiß schon, das ist jetzt alles sehr theoretisch "was wäre wenn vielleicht".
Die Wahrscheinlichkeit dass sowas in der Praxis vorkommt halte ich für eher gering.
Trotzdem kam es mir in den Kopf und vielleicht wisst ihr ja mehr als ich.

Dank im Voraus.

 

[besterino]

Korrekt, das Dateisystem kann nur schützen, was unmittelbar mit ihm gemacht wird. Es kann ja insbesondere nicht erkennen, ob eine auf einem anderen System gemachte Änderung gewollt war oder ein „Fehler“ ist. Das kann eigentlich nur der Anwender oder eine Prüfroutine erkennen, wenn er/sie merkt, dass irgendwas nicht mehr funktioniert oder Inhalte nicht stimmen.

Um sowas abzufedern (man merkt - meist ohne schon den Grund zu kennen, irgendwas ist JETZT verkehrt und muss einen Zustand finden, wo alles noch klar in Ordnung war) gibt es ZFS snaps. Die frieren einen gewissen Zustand auf Dateisystemebene ein und solange z.B. an einer Datei nichts geändert wird, fressen die quasi keinen Speicherplatz.

Man kann sehr granular festlegen a) wie oft und wann snaps angelegt werden sowie b) wie lange die „aufgehoben“ werden. Zu jedem noch vorhandenen Snap kannst du dann eben zurückkehren bzw. auf den Inhalt zugreifen.

Meist nimmt man eine Kombination aus recht kurzlebigen und langfristigen Snaps. Beispiel: alle 15 Minuten einen, die dann jeweils 1-2 Stunden aufgehoben werden, einen jeden Tag Nachts, den man 1-2 Wochen behält und einen pro Monat, den man dann mehrere Monate-Jahre aufbewahrt).

Aber am Ende hilft gegen ungewollte Datenveränderung am zuverlässigsten nur Sicherheit auf der ganzen Kette, inklusive Client-PC.

Zum Thema kopieren von einem Share auf ein anderes: das kann man natürlich auch lokal auf dem Server anschubsen - dann geht das nicht übers Netz. Bei ZFS gibt es für ganz datasets z.B. das hübsche Replication-Feature, aber im Prinzip ginge auch ein stumpfer Kopiervorgang - halt per Console/GUI oder sonst was nur eben direkt auf dem Server. Verschieben dann eben auch so.

 

[Canyon!]

Snapshots sind mir bekannt. Hat hiermit aber nichts zu tun.

 

[Trambahner]

Bei FreeBSD/FreeNas/Xigmanas mit Samba: Wenn man z.B. einen Pool mit mehreren Datasets einrichtet und den Ordner dadrüber als SMB-Share in Windows mapped, merken Windows und Samba dass beim Verschieben es am gleichen Server bleibt und geht nicht über den Client.

Beispiel:
/mnt sei der Ordner, in dem alle Pools und Datasets gemapped werden
/mnt/pool1 sei ein Zpool und /mnt/pool2 sei auch ein Zpool-
/mnt/pool1/dataset1
/mnt/pool1/dataset2
/mnt/pool2/dataset3
/mnt/pool2/dataset4

Wenn Du nun z.B. nur /mnt als SMB-Freigabe einrichtest und dieses in Windows mountest (also z.b. "net use m: \\server\mnt" (sofern mnt auch der Freigabename ist) , erscheinen ja die Pools und Datasets als Ordner in einem Laufwerk. Windows meint, du verschiebst nur zwischen Ordnern und löst die entsprechenden Kommandos über SMB aus.
Wenn Du dann z.B. von dataset1 nach dataset 2-4 was verschiebst, bleibt innerhalb des Servers und geht nicht übers Netz dann. Das funktioniert so dataset- als auch poolübergreifend.
Ist es nicht pool-übergreifend notwendig, dann reicht natürlich die Samba-Freigabe auf /mnt/pool1 oder /mnt/pool2 .

Verschiebst Du innerhalb des gleichen Datasets, verschiebt auch ZFS nur. Verschiebst Du zwischen Datasets oder Pools, kopiert ZFS server-intern um. Aber eben kein Transfer vom und zum Client.


Mountest Du in Windows auf verschiedenen Laufwerksbuchstaben, meine ich geht Windows über den Client.

Btw, Sowas gabs sogar schon zu Dos-Zeiten mit dem Lan-Manager und dem Netbeui-Protokoll. Statt dem normalen Dos-copy Befehl gab es da dann ein Kommando "net copy" oder "net move", wo dann die Nutzdaten nicht über den Dos-Client ging sondern server-intern bzw, Server-zu-Server Dateien bewegte.

Wie sich das auf Linux-ZFS oder Solaris/OmniOS verhält, kann ich Dir mangels Erfahrung nicht sagen. Linux (Proxmox/Debian) kann ich evtl. ausprobieren die Tage mal.

Damit das Arbeiten am Share angenehmer/performanter ist, hab ich zwei Pools: Einen HDD-Pool (Raidz2) für große Files, Archiv und co und einen extra SSD-Pool (Mirror vdev) für die Arbeitsdateien (und VMs).
Dadurch kann ich auch wenn ich vom HDD-Pool nichts brauch die HDDs in den Spindown schicken (ist nicht Goldstandard für ZFS, ich weiss. funktioniert bei mir aber) und die Kiste ist dann sparsamer und leiser.

 

[gea]

Es gibt immer Aktionen die trotz ZFS zu korrupten Daten führen können wenn diese außerhalb der ZFS Prüfsummen und Copy on Write Absicherung liegen. Dennoch ist der Hinzugewinn an Sicherheit durch ZFS im Vergleich zu Dateiytemen ohne diese beiden Sicherheitsmaßnahmen erheblich, insbesondere in Kombination mit Versionierung über readonly Snapshots. Idealerweise arbeitet man natürlich auf dem ZFS Filer und hat überall ECC RAM um vor unentdeckten RAM-Fehlern sicher zu sein (auch auf Clients bei kritischen Daten)

Verschieben von Dateien auf dem Linux/Unix Filer bedeutet immer ein Kopieren wenn damit verschiedene Shares oder ZFS Dateisysteme beteiligt sind, ansonsten werden nur die Metadaten geändert. Diese liegen bei ZFS doppelt vor und sind sehr sicher.

Ansonsten gibt es bei Daten-Transfers praktisch immer Prüfsummenkontrollen. Die sind zwar nicht so überragend gut wie die ZFS Kombination End to End Prüfsummen auf Daten und doppelten Metadaten gepaart mit Copy on Write, sorgen aber dafür dass PC Datenverarbeitung insgesamt etwas recht zuverlässiges ist.