[Sammelthread] ZFS Stammtisch

[andrer250282]

Hallo,

root@napp-it028:/tank/.zfs/snapshot# zfs list -r -t snapshot -o name,creation tank/daten
NAME                                                       CREATION
tank/daten@2019.03.07.11.01.56_Daten_Snapshot              Do. März  7 11:01 2019
tank/daten@1554105458_repli_zfs_napp-it028_nr_1            Mo. Apr.  1  7:57 2019
tank/daten@1554105458_repli_zfs_napp-it028_nr_2            Mo. Mai 13 10:36 2019
tank/daten@snapshotnight-1553600829_2019.10.17.18.00.15    Do. Okt. 17 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.18.06.00.15  Fr. Okt. 18  6:00 2019
tank/daten@snapshotnight-1553600829_2019.10.18.18.00.14    Fr. Okt. 18 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.19.06.00.14  Sa. Okt. 19  6:00 2019
tank/daten@snapshotnight-1553600829_2019.10.19.18.00.14    Sa. Okt. 19 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.20.06.00.14  So. Okt. 20  6:00 2019
tank/daten@snapshotnight-1553600829_2019.10.20.18.00.15    So. Okt. 20 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.21.06.00.14  Mo. Okt. 21  6:00 2019
tank/daten@snapshotnight-1553600829_2019.10.21.18.00.14    Mo. Okt. 21 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.22.06.00.15  Di. Okt. 22  6:00 2019
tank/daten@snapshotnight-1553600829_2019.10.22.18.00.14    Di. Okt. 22 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.23.06.00.15  Mi. Okt. 23  6:00 2019
tank/daten@snapshotnight-1553600829_2019.10.23.18.00.13    Mi. Okt. 23 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.24.06.00.13  Do. Okt. 24  6:00 2019
tank/daten@snapshotnight-1553600829_2019.10.24.18.00.15    Do. Okt. 24 18:00 2019
tank/daten@snapshotmorning-1553600792_2019.10.25.06.00.14  Fr. Okt. 25  6:00 2019

Und ja, Daten im Testverzeichnis werden jeden Tag geändert

Das mit den Vorgängerversionen fiel mir heute auf, weil es zum ersten Mal vom User benötigt wurde. Ich hab die Datei dann per Kommandozeile wiederhergestellt, war jetzt nicht der Aufwand, aber ich möchte dem User lieber Hilfe zur Selbsthilfe geben...

 

[martingo]

Kernel smb oder Samba?

 

[andrer250282]

Hm, ich hab alles über das nappit Interface gemacht, damit sollte das Kernel SMB sein, oder?

 

[gea]

Snapshots sind eine Eigenschaft eines ZFSDateisystems, genau wie SMB Shares unter dem Solaris SMB Server. Snaps als Windows vorherige Version gehen damit ohne weitere Einstellungen und normalerweise absolut problemfrei, wenn man mit der rechten Maustaste z.B. auf einen Ordner klickt und dann Eigenschaft > Vorgängerversion anwählt.

Probleme gibt es regelmäßig dann wenn unter OmniOS Dateisysteme geschachtelt sind und man in einem SMB Share in tieferliegende Dateisysteme wechselt oder wenn diese eindeutige Zuordnung Dateisystem=Share wie z.B. mit SAMBA nicht mehr gegeben ist. Oracle Solaris verhindert deshalb auch das Wechseln in tieferliegende Dateisystem.

Nach Möglichkeit daher freigegebende ZFS Dateisysteme nicht schachteln. Das kann auch zu ganz anderen Problemen führen, wenn man z.B. in einem Dateisystem Groß/Kleinschreibung als ZFS Eigenschaft beachtet und in einem anderen nicht oder aclmode/inherit unterschiedlich gesetzt hat.

 

[andrer250282]

@gea, vielen Dank für die Erklärung, aber so richtig weiss ich immer noch nicht was mein Fehler ist. Ich hab unter dem ZFS raid1z tank nur die Freigabe Daten, die wird als Netzlaufwerk verbunden und darunter ist direkt der Ordner um den es geht. Ist das verschachtelt?

 

[gea]

Nein.
Ein verschachteltes Dateisystem hätte man wenn man das Dateisystem tank/daten freigeben würde und darin ein weiteres freigegebenes Dateisystem z.B. tank/daten/bilder hätte. In OmniOS könnte man aus dem erstes Share direkt in das darunterliegende wechseln. Dieser Wechsel hätte einen anderen Snapordner auf ZFS zur Folge.

Wenn man nur ein Share hat, sollte das vollig problemlos gehen. Was passiert denn, wenn man mit der rechten Maustaste auf einen Ordner im Share klickt, in dem es Vorversionen geben müsste (Eigenschaft > Vorversionen).

Ist das Windows 10 Pro oder eine Home Edition. Letztere hat teils Einschränkungen beim Zugriff aufs Netz. Kann ich jetzt aber nicht beurteilen da ich auschließlich Pro habe.

 

[andrer250282]

Hallo,

es steht einfach nur "Es sind keine vorherigen Versionen vorhanden".
Alle Clients sind Win 10 Pro, alles 1903 und einer 1809. Das Problem ist aber bei allen vorhanden.

EDIT: es ist keine Domäne vorhanden falls das wichtig ist

 

[Trambahner]

Verschachteln kann ziemlich praktisch sein. Damit kann ich nen Windows Client ein Laufwerk auf ein einziges Share mappen, das dann in Unterverzeichnissen am Filer aus verschiedenen Datasets besteht. Nicht nur für getrennte Snaps, sondern auch um andere Dataset-Eigentschaften ändern zu können. Z.B. um Blocksize variieren zu können, Snaps getrennt zu syncen, ggf. verschiedene Kompressions- oder Copy-Settings.

Ich nutze es durchaus. Einzig die Mountpoints musste ich nal nach Transfer von Pools von altem zu neuen Filer wieder anpassen, damit die wieder passend waren.

 

[gea]

Verschachteln kann ziemlich praktisch sein. Damit kann ich nen Windows Client ein Laufwerk auf ein einziges Share mappen, das dann in Unterverzeichnissen am Filer aus verschiedenen Datasets besteht. Nicht nur für getrennte Snaps, sondern auch um andere Dataset-Eigentschaften ändern zu können. Z.B. um Blocksize variieren zu können, Snaps getrennt zu syncen, ggf. verschiedene Kompressions- oder Copy-Settings.

Ich nutze es durchaus. Einzig die Mountpoints musste ich nal nach Transfer von Pools von altem zu neuen Filer wieder anpassen, damit die wieder passend waren.

Ist ja nicht verboten oder gefährlich sondern eine Option in OmniOS. Man sollte sich halt im Klaren sein, wann ein Wechsel in ein "Unterverzeichnis" ein anderes Dateisystem bedeutet mit eventuell ganz anderen ZFS Eigenschaften.

- - - Updated - - -

Hallo,

es steht einfach nur "Es sind keine vorherigen Versionen vorhanden".
Alle Clients sind Win 10 Pro, alles 1903 und einer 1809. Das Problem ist aber bei allen vorhanden.

EDIT: es ist keine Domäne vorhanden falls das wichtig ist

ZFS Snaps = Windows Vorversionen tut eigentlich bei Solarish seit über 10 Jahren ohne viel Nachdenken. Benötigt auch keine Domäne. Ich muss jetzt erst mal überlegen, warum es nicht geht wenn es sonst einfach tut.

Da die Snaps ja angelegt sind, mal folgendes machen

- Dateisystem freigeben ohne guest access oder Optionen (smbshare=on)
- kein User ID,Mapping gesetzt
- SMB Zugriff auf \\serverip\sharename als user root (benötigt ein SMB Passwort, anlegen mit passwd root)
- Rechte Maustaste auf Ordner (Eigenschaft- Vorversion)

 

[Wesumat]

Hi gea,

ich wurde heute früh mit einer Meldung "Your PRO key has expired, you must renew in menu Extensions > register or downgrade to a free version in menu About > Update"
begrüsst.

Habe ich eventuell irgendwas nicht mitbekommen? Key ist nach meinem Verständnis schon eine Machine-Key gewesen. Hardware wurde auch nicht geändert, Rechner
läuft aktuell nur sporadisch, da noch in Testphase.

Der Key ist ein complete uncommercial home, unlimted, two keys. Der Versuch via website den lizenzkey zu tauschen klappt irgendwie nicht oder ich gebe den old key möglicherweise
im falschen Format ein (Meldung ist immer 'invalid key').

Schaut man in der /var/web-gui/_log/appliance.oldkey finde ich dort zumindestens am Ende einen Eintrag ' (wrong machine id 10.21.2019 ...' - nachvollziehen kann ich das im Moment
nicht.

Wie bekomme ich das nun wieder sauber zum Laufen?

 

[gea]

Falls sich die Machine id geändert hat:
Den Key online tauschen auf napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Extensions

alter Key z.B.
complete 1566122830_h:m0c291f3ddm90 - 18.6.2021::mVqnVqsmVOTTVuqmlqsmsViThhVD

In der ersten 19.06 konnte es passieren, dass der Key fälschlicherweise deaktiviert wurde (Machine ID hat sich nicht geändert).
Dann den alten Key (findet sich in Extension > Register > oldkey) erneut registrieren und auf aktuelle 19.06f updaten.

 

[Wesumat]

Hi gea,

der Weg hat so funktioniert, komischerweise war die Version schon auf 19.06f pro. Läuft auf jeden Fall jetzt wieder - Danke.

 

[gea]

Ein paar Einsichten zum neuen ZFS Feature Allocation Classes
http://napp-it.org/doc/downloads/special-vdev.pdf

1. About Allocation Classes
2. Performance of a slow diskbased pool
3. With special vdev (metadata only)
4. With special vdev (for a single filesystem)
5. With special vdev (for a single filesystem) and Slog (Optane)
6. Performance of a fast diskbased pool
7. Fast diskbased pool vwith special vdev
8. NVMe Pool vs special vdev (same NVMe)
9. Compare Results
10. Conclusion
11. When is a special vdev helpful
12. When not
13. General suggestions

 

[JohnnyBGoode]

Wäre jemand so nett, eine Stichpunkt-Skizze zu geben, wie man ein etwas spezielleres bare metal installiertes Windows vollständig auf einen 40 GbE-ESXi-Oracle-ZFS-napp IT-Server mit Snapshots sichern kann?

Ausgangsbasis wird ein "FuzeDrive 1000" mit Optane 905P 480 GB für das "hart rangenommene" Tier, wo vor allem die Schreibperformance nicht einbrechen soll, als "lahmes" Storage-Tier ist eine Western Digital Ultrastar DC SN630 mit 7,68 TB rangekoppelt. Um alles noch schöner zu machen, ist das Ganze mit Bitlocker verschlüsselt, da VeraCrypt einfach zuviel Performance bei NVMe-Laufwerken kostet

Die Leistung vom FuzeDrive wird zwar laut Support von der Windows-Storport-Architektur eingebremst, hier soll bald eine neue Version mit eigenem, leistungsfähigerem Unterbau erscheinen, auf die man updaten kann, ohne, dass man das System neu eingerichet werden muss.

(Diese Kombination wird vom FuzeDrive offiziell unterstützt, habe ich schon mit deren Support, der übrigens sehr kompetent antwortet, abgeklärt)

Ein paar Anmerkungen:

- Im Falle eines Ausfalls können die lokalen Laufwerke gerne vollständig plattgemacht werden, um sie neu einzurichten

- Externe USB-SSDs sind vorhanden, die beispielsweise ein Linux/Windows booten könnten, um dann wiederum die internen NVMe-Laufwerke neu einzurichten

Wie immer vielen Dank für die Tipps!

 

[gea]

Ich verstehe eventuell das Problem nicht vollständig.

Wenn es aber lediglich darum geht, eine Windows Systemsicherung auf dem NAS abzulegen und im Crashfall wiederherzustellen, so nehme ich dazu Aomei. Sichern geht aus Windows und Disaster-Recovery mit einem USB Stick (kann man aus Aomei erstellen) mit Windows PE oder Linux drauf.

Alternativ könnte man den Rechner auch mit einem USB Stick mit Clonezilla booten. Damit kann man dann System Backup + Baremetal Restore erledigen.

Letzte Option wäre Windows von iSCSI (auf Solaris zu Booten). Dann gäbs gar keine lokalen Bootplatten und man könnte mit den ZFS Performance Features (RAM-Cache, spezial vdev, Slog etc) arbeiten.

 

[JohnnyBGoode]

Bin wahrscheinlich wegen BitLocker etwas verunsichert was Backups angeht, da ich dieses noch nie verwendet habe (bei Windows habe ich sonst nur DiskCryptor oder VeraCrypt verwendet, aber deren Treiber schlucken einfach zu viel Leistung weg). Dazu kommt, dass ich sonst immer nur Daten und keine ganzen Installationen gesichert habe (und zum Glück nie Probleme damit hatte). Aber das alles will ich jetzt "besser" lösen und die Schlamperei beenden.

An iSCSI habe ich schon gedacht, das nehme ich vielleicht für separate "nicht OS-Daten"-Datenträger her, allerdings soll - wenn ich richtig recherchiert habe - ein Diskless-Windows-Boot-System ein ziemlicher pain-in-the-ass im Alltag sein, auch was das Einspielen von Updates angeht, wo dann teilweise Windows nicht mehr richtig bootet. Auch soll iSCSI bei Windows nur einen Kern verwenden, wodurch die Leistung trotz R7 3700X/4,4 GHz auf Server-Seite und (bald) R9 3950X/4,7 GHz auf Klient-Seite im Vergleich zur nativen NVMe-Laufwerken deutlich langsamer sein soll.

 

[gea]

iSCSI Boot habe ich nur der Vollständigkeit halber erwähnt, würde ich ich mir vermutlich auch nicht ohne Not antun.

Ansonst ist mein bevorzugtes Setup auch OS + Programme + allenfalls ganz zeitkritische Sachen lokal auf NVMe. Das dann ab und an als Systemsicherung für Disaster Recovery sichern. Alle Daten liegen ausschliesslich auf einem ZFS Filer und damit versehen mit Prüfsummen, hohen Redundanz Leveln, Dateisystem-Verschlüssellung und den ganzen Tuning Optionen. Mit readonly filebasierten Snaps (iSCSI kann nur Volume-Snaps) dann Kurzzeit Versionierung bis herunter alle 15 Minuten und Langzeitversionierung täglich, wöchentlich, monatlich etc auch als Schutz vor Ransomware.

Den ZFS Filer selber dann als Disaster Backup auf einen weiteren removable Pool oder entfernte Appliance sichern. Das geht neuerdings sogar verschlüsselt (RAW Backup eines verschlüsselten locked Dateisystems)

 

[JohnnyBGoode]

Noch eine grundsätzliche Frage:

Das lokale System-Volume hat ja etwa 8 TB, gibt es die Möglichkeit, dass nur einmal ein großes Backup für Disaster Recovery gemacht wird und danach nur Delta-Sicherungen gemacht werden (oder geht das nur nei einzelnen Ordner/Dateien, nicht mit wirklich allem an Informationen inkl. Partitionen etc.?)...

...und wenn das System "richtig" im Eimer ist, ein USB-System zu booten, und dann Snapshot xy vollständig (im Extremfall 8 TB) wiederherzustellen, aber auf dem Server nur beispielsweise insgesamt 9 TB mit diversen Snapshots belegt sind?

Danke nochmal für Dein Feedback und ich hoffe, dass Du nicht von solchen Anfängerfragen genervt bist.

 

[gea]

Lokales System Volume= 8TB ??

Wenn das Windows ist, bedeutet das lokale Datenhaltung. Ransomware hat darauf direkten Zugriff, keine Crashsicherheit/ Absturz beim Schreiben kann das Dateisystem schrotten, es gibt keine Prüfsummensicherheit und keine sicheren Snaps. Backup kann man zwar inkrementell machen, dennoch: würde ich nie nicht machen (Alle Daten gehören aufs NAS/SAN). Ein Restore von 8TB braucht im Disasterfall auf jeden Fall Tage.

Wenn das Solarish ist, so ist das auch unüblich. Da hat eine Systemplatte max 100 GB und keine Daten. Raucht die ab, braucht man idealerweise kein Backup. Neuinstallation auf eine neue SSD, Import des Datenpools und 15 Minuten später ist alles wieder online. Einen ZFS Datenpool sichert man per ZFS Replikation (Hält auch Multi-Petabytes eines Hochlastserver mit 1 min Delay syncron mit dem Backup-Pool)

 

[JohnnyBGoode]

Ja, das lokale bare metal Windows-System soll 8 TB haben. Der direkt angebundene 40 GbE-ESXi-Oracle-ZFS-napp IT-Server hat für sein OS selber einen "normal großen" SSD-Speicherplatz (RAID1), 128 GB RAM, Optane für L2ARC+ZIL und über HBA/SAS3-Expander (Broadcom 9400 8i8e/Intel RES3TV360) Zugriff auf 32 mechanische HDDs, wovon jeweils 8 Stück ein RAIDZ2 bilden und damit 4 unterschiedliche "Verwendungszwecke" abgedeckt werden - und ein 8er Pack HDDs hat eben unter anderem den Verwendungszweck "Sicherungen der bare metal Windows-Installation des einen Klienten mit dem übertrieben großen 8 TB FuzeDrive-Systemlaufwerk".

Wäre auch cool, wenn man Ordner des bare metal Systems von der Snapshot-Sicherung ausschließen kann, damit man beispielsweise Daten, die sowieso auf dem Server liegen, aber die für die leistungsfähigere Weiterbearbeitung lokal rüberkopiert wurden, nicht doppelt abspeichert.

"Aber" es soll eben auch ein fertig bootfähiges System mit allen Programmen/lokalen Dateien mit zwei völlig blanken NVMe-Laufwerken über die auf dem Server liegenden Sicherungen/Snapshots wiederhergestellt werden können.

Sonst bin ich immer mit SATA-SSDs in RAID1/10 lokal für das System gefahren, für tiered storage und NVMe-Laufwerke gibt es aber meines Wissens nach nichts, womit man auch mit Windows davon booten kann, dazu würde das den Preis doch arg hochtreiben, da mit der jetzigen Planung ohne RAID1/10 beim Klienten und nur zwei lokalen NVMe-Laufwerken die Sache mit einem kleinen X570-Mainboard erledigt ist (die Optane bekommt PCIe 3.0 x4 von der CPU, die Western Digital NAND 7,68 TB-SSD PCIe 3.0 x4 vom X570-Chipsatz).

Ist dafür da, dass man vollkommen lokal herumfuhrwerken kann (für einzelne große Projekte, dateibasiert), dann bei Bedarf sich neues Material vom Server holt oder eben fertige Daten dort ablegt. Dass es in diesem Zeitraum bei einem Ausfall der lokalen SSDs zu Datenverlust kommt, ist mir klar, aber irgendwo "muss" der Haken ja sein, wenn man auf NVMe-Laufwerke umsteigen möchte und dennoch Windows bare metal laufen soll.

Ironischerweise hat die Western Digital Ultrastar DC SN630 in der 8 TB-SSD-Klasse sogar ein ziemlich gutes Preis/Speicherplatz-Verhältnis für SSDs generell (inkl. SATA), die nicht auf QLC-NAND zurückgreifen sollen.

 

[gea]

8 TB lokal bedeutet dass man immer Daten hat, die nicht auf sicherem Storage liegen.

Was ist denn der entscheidende Grund, nicht die Daten prinzipiell aufs NAS/SAN zu legen und lokal nur "Spielwiese" anzubieten, dann eventuell mit einer Intel Optane die wirklich unschlagbar schnell ist aber nur unter 1TB bezahlbar?

Auch wenn es spezielle vdev (einzelne high Performance ZFS Dateisysteme auf NVMe) nicht auf Solaris gibt, so könnte man da auch einen kleineren High Performance NVMe Pool und einen größeren allgemeinen anbieten. Lokale Performance mag ja dennoch schneller sein, die Frage ist doch ob zentrales NAS ausreichend schnell ist um die Nachteile der lokalen Speicherung zu vermeiden oder ob die zusätzlich erreichbare lokale Performance entscheidend wichtig ist.

Wenn eine lokale 8TB wirklich wichtig ist, würde ich eine kleine <1TB Partition für OS und Programme machen und eine große für Daten. Die OS Partition ab und an als Recovery Systemsicherung backuppen. Die Datenpartition dann täglich oder öfter als geplanten Task mit robocopy aufs NAS spiegeln.

 

[JohnnyBGoode]

Stimmt eigentlich auch wieder.

Glaube, mein Gedankengang war in etwa folgendes:

Das bisherige System, das abgelöst wird, hat für Windows und Programme 4 x 1 TB Samsung Evo 850 SATA PCH-RAID 10 (also 2 TB nutzbar). Bei Intel "passt" das Chipsatz-Software-RAID ja leistungsmäßig einigermaßen, wenn man RAID 0, 1 oder 10 nimmt, also bei RAID 1 hat man bespielsweise 1n einer einzelnen SSD Schreibperformance und 2n Leseperformance (sequenziell), wie es sich gehört (leider nicht 4n bei RAID 10)

Habe dann mal vor einem Jahr bei einem X470-Mainboard dessen Chipsatz-SATA-Software-RAID1 getestet und dessen Performance war beim Lesen gammlig, warum auch immer. Daher hatte ich in Erinnerung: AMD-Chipsatz-Software-RAID1 ist schlecht, besser nicht nutzen.

Mit dem bisherigen RAID 10 hab' ich ja 2 TB für alles, das war mir schon etwas zu knapp - der Rest lag auf Server mit LSI-Hardware-RAID6 extern. Wenn ich nun schon aufrüste, wollte ich mich platzmäßig (lokal) deutlich verbessern. Habe noch 2 x 2 TB Evo 860 herumliegen, damit könnte ich beim X570 nochmal RAID1 testen, wenn wirklich nur OS+Programme+Sample-Bibliotheken dort liegen, könnte ich mit 2 TB nutzbaren Platz nur dafür hinkommen, wenn dann parallel das FuzeDrive mit Optane+WD NAND SSD für temporäre Dateien zum Herumspielen dazukommt.

Das klingt objektiv vernünftiger, aber irgendwie "wurmt" es mich vom Bauchgefühl immer, dass sich im Bereich von Tiered Storage nicht mehr tut, um einfach jedes bisschen Speicherplatz optimal auszunutzen. Am liebsten wären mir ja ein Tiered Storage RAID 1 mit 2 x (Optane + NAND NVMe), aber dafür gibt es ja keine Lösung, von der Windows booten könnte - vom Preis und den notwendigen PCIe-Lanes her mal abgesehen.

 

[gea]

Klingt für mich nach "in Schönheit sterben"

Eine lokale Optane vs einem Raid-10 Evo vs einer beliebig billigen NVMe Platte sehe ich für das OS und lokale Programme als nicht relevant an. Gleiches gilt für eventuelles Tiering zwischen diesen Devices - wobei Tiering unter Last eh kontraproduktiv ist und Raid-10 aus Desktop NVMe weit unter einer Optane bleibt. Die Latenz wird halt nicht besser sondern schlechter und sequentiell ist eine einzelne NVMe bereits jenseits von gut und böse.

Keep it Simple. Das ist meine erste Devise. Es mag zwar die eine oder ander Oracle oder SAP Anwendung geben wo das lokal einen Unterschied macht oder eine Highspeed Gaming Session. Ansonstem gilt das was mein Kollege (aus dem Schwäbischen) gerne von sich gibt: Ist mir schnurzz..

 

[JohnnyBGoode]

Die Optane beim Windows-System bzw. dem FuzeDrive wird auch nur verwendet, da man sie beschreiben kann wie man will und es ihr völlig egal ist, wie viel Platz noch frei ist oder TRIM ausgeführt wurde, solange sie ordentlich gekühlt wird, liefert sie sequenziell 2700MB/2500 MB, die Latenz spielt hier für mich keine Rolle.

*Edit*: Stimmt ja auch, eine Optane ist dafür eigentlich verschwendet, gucke noch, ob ich eine 970 Pro freibekomme, durch ihren MLC NAND dürfte sie alles, was ich dort mit ihr anstellen möchte, mitmachen.

Beim SATA-SSD-RAID ist es halt praktisch, wenn die Lesevorgänge schneller durch das parallele Lesen von mehreren SSDs abgeschlossen sind und die SSDs dann frei für's Schreiben sind, da ja SATA anders als SAS oder NVMe nicht gleichzeitig lesen und schreiben kann.

 

[Luckysh0t]

Wenn man eine Kopie seiner Daten vom ZFS Filer auf ein normales NAS (qnap, Synology etc) machen möchte, was wäre sinniger - abgesehen von einem weiteren ZFS Filer ^^

Die HDDs über das NAS als Mirror und dann per iSCSI ans ZFS
Die HDDs einzeln per iSCSI ans ZFS und dort ein Mirror erstellt

So könnte man zfs send nutzen - auch bei Systemen die kein ZFS haben.

 

[martingo]

Auf jeden Fall die zweite Variante. Wenn auf einem iscsi device Fehler auftreten, kann er diese vom anderen holen.
Bei der ersten Variante ist es dann schon zu spät weil der Fehler auch auf die andere Platte gespiegelt wird.

 

[gea]

+1
Auf jeden Fall die zweite Variante.
Aus Sicht von ZFS sind das zwei Platten als ein ZFS Raid unter voller ZFS Kontrolle.

Fall 1 ist aus Sicht von ZFS eine einzelne Platte. Wird da ein Prüfsummenfehler erkannt, kann der von ZFS nicht repariert werden. Hinzu kommt das "Write Hole Problem" bei einem normalen Mirror. Da werden die Daten beider Platten nacheinander aktualisiert. Ein Absturz beim Schreiben sorgt dafür dass beide Platten unterschiedlich sind. Das kann neben einem inkonsistenten Mirror zu einem defekten Dateisystem führen. Ein "normaler" Mirror kann das Problem im Gegensatz zu ZFS weder wirklich erkennen noch reparieren.

 

[Stueckchen]

Rein von der Datensicherheit her klarer Fall.
Aber bedenke im 1. Fall müssen die Daten ja 2 mal über das Netzwerk, also halbierst du die Bandbreite. Eine Syno sollte/könnte ja mit BTRFS auch Checksums unterstützen (bin mir aber nicht sicher).

 

[martingo]

Dann darf er aber kein iscsi verwenden. Das ist als Blockdevice wie eine entfernte Festplatte. Ohne jegliches Dateisystem.
Bei einem BackupNAS sollte der doppelte Traffic zu vernachlässigen sein. Vor allem weil er ja sicher inkrementell sicher (Verweis auf zfs send).

 

[Luckysh0t]

Danke für die Antworten.

Bez. der Datenrate sehe ich das nicht so eng, wird evtl. 10 Gbit bekommen.Und wenn nicht, der große Schwung an Daten kommt ja nur einmal ^^