Setup-Fragen zu ZFS, Cache und Bit-Rot Protection

[_Sascha_]

Hallo zusammen,

 

ich bin neu hier und habe dieses WE mein UNRAID Server zum ersten Mal aufgesetzt. Allerdings habe ich mich während der 13 Stunden der Parity-Drive-Generierung, im Internet ein wenig schlau gemacht und bin auf interessante Aussagen gestoßen, die leider meist nur in Kommentaren am Rande erwähnt wurden und noch doch Fragen aufwerfen.

Fragen

1.  UNRAID bis jetzt nicht voll kompatibel zu ZFS 
   
   Als Pool kann man sie schon anlegen und für Freigaben verwenden. Aber ohne zu tricksen (Annahme auf Basis von Symlinks), können diese von Docker, VMS und den UNRAID Plugins nicht verwendet werden. Was heißt, es wird empfohlen, auf UNRAID's Standard BTRFS und XFS zu setzen. Stimmt ihr dem zu?
   
   Des Weiteren braucht man selbst bei ZFS Pools mindestens eine Festplatte (oder USB-Stick als Dummy) im Array, damit UNRAID funktioniert, korrekt?
    
2. Cache sollte immer ein Pool sein (wegen Bit-Rot Protection)
   
   Hier habe ich die größten Kopfschmerzen, ich habe nur ein NVMe Slot und dachte den NVMe nutze ich als Cache. Aber anscheinend wird immer ein Pool vorgeschlagen.
   
   - Mein Board hat zwar noch neben dem M.2 Slot ein vertikalen Half-size Mini-PCI Express Slot (für Wi-Fi + BT Modul), aber ich weiß nicht, ob sie dies irgendwie zu einem zweiten M.2 Slot mit oder ohne entsprechenden Adapter/Controller umwandeln lässt.
   - Wenn nicht, würde mir nur die Möglichkeit bleiben, eine weitere SATA SSD zu kaufen und anstelle der NVMe die beiden SATA-SSDs als Cache einzurichten. (oder brauche ich drei?)
    
3. Bit-Rot nur mit BTRFS/ZFS Pools
   
   Wie wichtig ist die Bit-Rot Protection für die Festplatten? Wenn man den Schutz haben will, kommt man anscheinend um ein BTRFS/ZFS nicht herum, oder?

 

Aktuelle Hardware

CPU

• Intel Xeon E5-2699V3 18 Core

BOARD

• ASRock X99E-ITX/ac

RAM

• 2x Samsung 32 GB ECC RAM

SATA

• 3x WD PRO (10 TB) NAS Festplatten als Array
• 1x Samsung Pro SM883 (960 GB)  als Single-Drive

NVME

• 1x Samsung 970 Pro (960 GB) als Cache

 

Geplanter Einsatzzweck

• Einige Webserver Applikationen wie Nextcloud, piHole, pfSense und Dateiserver über Docker
• Vielleicht eine Windows VM für ältere Hardware (meist kalt)
• Netzwerk-Freigaben für Backups, größere Mediendaten und Alt-Daten, die man ungern aufgibt

 

Sonstiges

• Zwei der WD RED Festplatten, stammen von einem älteren Proxmox Build, also es handelt sich hier nicht um die gleiche Charge.

[alturismo]

1 hour ago, _Sascha_ said:

die leider meist nur in Kommentaren am Rande erwähnt wurden und noch doch Fragen aufwerfen.

vorab, mal in den passenden Bereich geschoben ...

 

 

1 hour ago, _Sascha_ said:

können diese von Docker, VMS und den UNRAID Plugins nicht verwendet werden. Was heißt, es wird empfohlen, auf UNRAID's Standard BTRFS und XFS zu setzen. Stimmt ihr dem zu?

wo steht das ?

 

auch zfs pools können dafür genutzt werden ...

 

1 hour ago, _Sascha_ said:

Cache sollte immer ein Pool sein (wegen Bit-Rot Protection)

Hier habe ich die größten Kopfschmerzen, ich habe nur ein NVMe Slot und dachte den NVMe nutze ich als Cache. Aber anscheinend wird immer ein Pool vorgeschlagen.

auch das ... wo steht denn sowas ... hier vermischst du eher was ...

 

cache sollte im Pool sein wegen Ausfall Sicherheit ... oder (wie ich) eine Backup Strategie verfolgen ....

 

Bit Rot ist etwas ganz anderes ... bitte mal einlesen, nachdenken, dann nochmals fragen ...

 

1 hour ago, _Sascha_ said:

Bit-Rot nur mit BTRFS/ZFS Pools

Wie wichtig ist die Bit-Rot Protection für die Festplatten? Wenn man den Schutz haben will, kommt man anscheinend um ein BTRFS/ZFS nicht herum, oder?

siehe den Punkt darüber ... einlesen ...

 

kurze Info vorweg, du hast ECC Ram ... Bit Rot ... einlesen !

 

1 hour ago, _Sascha_ said:

Des Weiteren braucht man selbst bei ZFS Pools mindestens eine Festplatte (oder USB-Stick als Dummy) im Array, damit UNRAID funktioniert, korrekt?

ja, Unraid basiert auf einem Array und nicht auf pool/s ... daher braucht es ein Array, und sei es ein USB Dummy ...

 

1 hour ago, _Sascha_ said:

Geplanter Einsatzzweck

• Einige Webserver Applikationen wie Nextcloud, piHole, pfSense und Dateiserver über Docker
• Vielleicht eine Windows VM für ältere Hardware (meist kalt)
• Netzwerk-Freigaben für Backups, größere Mediendaten und Alt-Daten, die man ungern aufgibt

 

Sonstiges

• Zwei der WD RED Festplatten, stammen von einem älteren Proxmox Build, also es handelt sich hier nicht um die gleiche Charge.

Fragen dazu lauten ?

 

reicht der Server dafür ... ja, ist es Unraid egal aus welcher Charge die Platten kommen, ja ...

[_Sascha_]

2 hours ago, alturismo said:

wo steht das ?

 

auch zfs pools können dafür genutzt werden ...

 

Ich müsste durch alle Reddit/UNRAID-Posts gehen, die ich gelesen habe.

 

Aber wenn du es dementierst, scheine ich da wirklich etwas missverstanden zu haben.

 

2 hours ago, alturismo said:

auch das ... wo steht denn sowas ... hier vermischst du eher was ...

 

cache sollte im Pool sein wegen Ausfall Sicherheit ... oder (wie ich) eine Backup Strategie verfolgen ....

 

Bit Rot ist etwas ganz anderes ... bitte mal einlesen, nachdenken, dann nochmals fragen ...

 

In fast jeder Diskussion über den Cache wird meist eine Pool-Konfiguration für den Cache empfohlen.  Entsprechend scheinen die meisten Nutzer die Sorge vor fehlerhaften Daten sehr ernst zu nehmen und so die Gefahr von verhalft gespeicherten Daten minimieren zu wollen.

 

Mir ist schon in der Theorie bewusst, was Bit-Rot ist. Aber wenn du so reagierst, nehme ich an, dass die Bezeichnung von verortenden Bits auf inaktiven Medien auch für fehlerhaft gelesene/geschriebene Daten falsch verwendet wird. Durch die Duplikation der Daten ist durch den Vergleich zumindest bei einem RAID mit entsprechendem Pool und Dateisystem möglich, diese frühst möglich zu erkennen und ggf. sogar zu korrigieren.

 

Wären dies dann fehlerhaften Daten-Bits oder wie ist die korrekte Bezeichnung dafür?

Du bist der Erste, welcher erwähnt, dass die externe Backup-Strategie bereits ausreichen würde. Heißt es reicht, wenn ich den Cache regelmäßig auf einen ZFS Pool sichere und diesen extern sichere, korrekt?

 

2 hours ago, alturismo said:

siehe den Punkt darüber ... einlesen ...

 

kurze Info vorweg, du hast ECC Ram ... Bit Rot ... einlesen !

 

Bei RAM ist die Wahrscheinlichkeit für DataBit-Fehler (Bitflip) zwar geringer, aber dieser kann auftreten, weshalb ECC RAM zu Einsatz kommt. Allerdings, was hat ECC-Ram mit den Dateisystemen und Festplatten zu tun?

 

Ich habe mich schon gefragt, ob ECC RAM fehlerhafte Daten vorbeugen könnte, aber wenn etwas während des Schreib-/Lese-Vorgangs passiert (Strahlung, Spannung), könnte ich mir gut vorstellen, dass da der ECC-RAM nicht viel hilft und deshalb auf entsprechende Pools und Dateisysteme zurückgegriffen wird.

 

Darum auch all diese Fragen. Selbst wenn die Daten auf dem Home-Server nicht kritischer Natur sind (solche sind bereits im Backupzyklus), möchte ich die Datenintegrität so weit wie möglich gewährleisten.

 

2 hours ago, alturismo said:

Fragen dazu lauten ?

 

reicht der Server dafür ... ja, ist es Unraid egal aus welcher Charge die Platten kommen, ja ...

 

Keine Fragen, die Informationen habe ich niedergeschrieben, falls die Frage aufkommt.

 

Edited April 2 by _Sascha_
Readability

[alturismo]

50 minutes ago, _Sascha_ said:

sehr ernst zu nehmen und so die Gefahr von verhalft gespeicherten Daten minimieren zu wollen.

da geht es sicher um Ausfall ... vor allem bei btrfs Platten, xfs single drive sind in Summe "rock solid".

 

wenn dir die Datenverfügbarkeit in Echtzeit wichtig ist, dann ist ein pool (raid) Pflicht, wenn dir beispielsweise daily backups reichen (wie hier beispielsweise) dann reicht auch single drive mit Backup Strategie ...

 

Bit-Rot ist das fehlerhafte Schreiben (meist durch defekten Ram) ... da hilft der beste Pool nichts ... was kaputt ankommt ... ist kaputt

dafür ist die Diskussion bzgl. ECC Ram gefragt ... daher sage ich ja, einlesen ... ECC Ram wird genutzt um dem Bit Rot vorzubeugen ...

 

zfs noch dazu um entstehende Fehler ggf. zu korrigieren welche durch das Dateisystem entstehen, wobei hier halt Raid Modi (egal ob btrfs, zfs, ...) anfälliger sind ... aber egal, das ist eine "Glaubensfrage" ... zfs ist für mich persönlich eher ein Datacenter Thema und kein Homeserver Thema, aber auch da ... jeder für sich und wie er sich wohl fühlt

 

in Summe, mit ECC Ram und zfs hast du 99,9 erschlagen zum Thema Bit Rot, also, bleib dabei

 

zfs raidX werden halt nie das Unraid Array erreichen da dies sich widerspricht, ein Raid Pool ins UNRaid ... aber das Schöne ist, du hast die Wahl  passt.

[hawihoney]

7 hours ago, _Sascha_ said:

die leider meist nur in Kommentaren am Rande erwähnt wurden

 

Da ist sehr viel Quatsch dabei.

 

Das Unraid Array ist traditionell für die Datenablage gedacht. Pools für einen schnellen Schreib-Cache, Container, VMs. Alles kann auf allem laufen. Die Performance Anforderungen treffen die Entscheidung, was man wohin packt.

 

Bit-Rot halte ich persönlich für einen esoterischen Mumpitz. In den von mir seit nun 16 Jahren betreuten Unraid Servern ist noch kein Bit umgefallen. Und wir reden hier von hunderten Platten in Unraid Arrays. Das wäre bei Parity-Checks aufgefallen.

 

Sorg dafür, dass der Rechner nicht hart runter kracht oder runter gefahren wird. Das verhindert Probleme.

 

[DataCollector]

On 4/2/2024 at 7:35 PM, _Sascha_ said:

In fast jeder Diskussion über den Cache wird meist eine Pool-Konfiguration für den Cache empfohlen.  Entsprechend scheinen die meisten Nutzer die Sorge vor fehlerhaften Daten sehr ernst zu nehmen und so die Gefahr von verhalft gespeicherten Daten minimieren zu wollen.

 

Die Gefahr eines Datenträgerausfalles wird sehr ernst genommen (und im privaten Umfeld bei kleinen System, mit <10 Datenträgern, sogar etwas zu ernst [persönliche Meinung]).

Wenn man jetzt nicht wirklich lebenswichtige Sachen macht (und das ist dann eher unternehmensrelevante Nutzungen), sind die Sachen, die im Pool/Cache liegen entweder so frisch, daß man sie neu erstellen wiederbeschaffen kann (weil der Cache ja eigentlich ab und zu geleert und ins Array verschoben wird) oder eher statisch (Docker/VM). Davon in regelmäßigen Abständen ein Backup anzulegen und schon hat man auch einen Datenschutz (der zwar den unternehmenskritischen Weiterbetrieb zu Arbeitszeiten nicht abdeckt, aber im privaten Umfeld bei dem man nicht seine 20 Angestellten bei Serverausfall vielleicht weiter bezahlen muß) erfüllt.

 

Und bei den Pools mit mehreren Datenträgern geht es nicht um Probleme bei der Datenintegrität/Bitrot, denn das kann unraid selber gar nicht so genau feststellen, sondern eben Ausfallsicherheit.

Klar, zfs in Pools, in seiner endgültigen Form kann auch die Datenintegrität abdecken, aber das ist dann eher ein erfreulicher Nebeneffekt, der Dir dann aber später im Array auch wieder nichts bringt.

 

Gegen Bitrot hilft (mehrere) Backups anfertigen und ggf. die Dateien regelmäßig auf Korrektheit prüfen (entweder Backup mit Quelle binär vergleichen oder extra Checksummen oder so.)

 

On 4/2/2024 at 7:35 PM, _Sascha_ said:

Durch die Duplikation der Daten ist durch den Vergleich zumindest bei einem RAID mit entsprechendem Pool und Dateisystem möglich, diese frühst möglich zu erkennen und ggf. sogar zu korrigieren.

 

Unraid ist kein Raid.

Und wenn man (beispielsweise ich) ein Raid in einem Pool aufmacht ist das meist wegen anderer Beweggründe.

 

On 4/2/2024 at 7:35 PM, _Sascha_ said:

Du bist der Erste, welcher erwähnt, dass die externe Backup-Strategie bereits ausreichen würde.

 

Dann bin ich die zweite Person.

Wobei hier klar anzumerken ist: eine Backupstrategie ist mehr als ein Satz Festplatten im Regal. Eine solche Strategie umfasst Generationen von Backups und eben auch die Überprüfung des binären Status, denn sonst schleppt man sich da kaputte Dateien einfach von Generation zu Generation weiter.

Deshalb nutze ich halbautomatisch erstellte Checksummen. So kann ich bei Problemen recht schnell sehen wo/welche Datei beschädigt ist und auch feststellen, ob die Datei in einem Backup vielleicht noch OK ist.

 

On 4/2/2024 at 7:35 PM, _Sascha_ said:

Heißt es reicht, wenn ich den Cache regelmäßig auf einen ZFS Pool sichere und diesen extern sichere, korrekt?

 

Den Cache einfach irgendwo hin zu sichern und die Integrität ab und zu zu prüfen reicht. Das muß kein zfs sein.

 

On 4/2/2024 at 7:35 PM, _Sascha_ said:

Bei RAM ist die Wahrscheinlichkeit für DataBit-Fehler (Bitflip) zwar geringer, aber dieser kann auftreten, weshalb ECC RAM zu Einsatz kommt. Allerdings, was hat ECC-Ram mit den Dateisystemen und Festplatten zu tun?

 

Alles, was durch den PC läuft, läuft durch den RAM.

Egal ob nun von einem Lan Kontroller zu den Pool(s) oder von Pools zum Array oder von GPU(funktion) zur CPU und dann zum Lan.... alles läuft über den Ram (und weil das die CPU zu sehr stressen würde, hat man ja auch DMA etabliert. Weil ohne Memory Access gar nichts läuft).

 

 

On 4/2/2024 at 7:35 PM, _Sascha_ said:

Ich habe mich schon gefragt, ob ECC RAM fehlerhafte Daten vorbeugen könnte,

 

Je nachdem welche Art von ECC man einsetzt kann es ein oder gar 2 gekippte Bits erkennen oder auch beheben/korrigieren oder zumindest das System stoppen, bevor es mit falschen Ramdaten weiter arbeitet und sich das Problem fortsetzt.

Ein Fehler im Ram, aufgrund dessen das System stoppt/abstürzt ist zwar ärgerlich, aber eben genau das: ein flüchtiger Fehler.

Wenn der Fehler aber unentdeckt ist/bleibt, kann es sein, daß komplett falsche Befehle ausgeführt werden und dann (um es mal komplett übertrieben zu sagen) aus einem gewünschten 'Paritycheck' ein eher nicht erwünschtes 'Format all Devices' bei raus kommt und ausgeführt wird.

Dann doch lieber einen Absturz. 😃

 

Aber ECC ist in meinen Augen im Privatbereich etwas überbewertet.

Klar ich habe bei einem meiner unraidsysteme auch mal auf ECC gesetzt, aber alles andere bei mir läuft mit normalem Ram.

Backups sind da (in meinen Augen in meinem Privatumfeld wichtiger).

 

On 4/2/2024 at 7:35 PM, _Sascha_ said:

aber wenn etwas während des Schreib-/Lese-Vorgangs passiert (Strahlung, Spannung), könnte ich mir gut vorstellen, dass da der ECC-RAM nicht viel hilft und deshalb auf entsprechende Pools und Dateisysteme zurückgegriffen wird.

 

Du hast recht: ECC wird gegen die Strahlung eines Atomschlages in ungefär 2m Entfernung dann vielleicht nicht mehr als wirksamer Schutz für die IT und Dich helfen.

Und Spannungsprobleme: eine UPS kann helfen.

 

On 4/2/2024 at 7:35 PM, _Sascha_ said:

Darum auch all diese Fragen. Selbst wenn die Daten auf dem Home-Server nicht kritischer Natur sind (solche sind bereits im Backupzyklus), möchte ich die Datenintegrität so weit wie möglich gewährleisten.

 

Dann empfehle ich gleich in die Vollen zu gehen! Ein redundantes (gedoppeltes) Serversystem mit allem Schnick und Schnack, aber bitte auch in 2 weit von einander getrennten Rechenzentren mit entsprechenden Sicherungen (Feuer, Stromausfall, Blitzeinschlag, Waser, Vandalisums....) .  Wird zwar vielleicht etwas teurer, aber das wäre dann "so weit wie Möglich".

Wenn wir ein paar Jahrzehnte/Jahrhunderte weiter sind, kanns Du eines der Systeme vielleicht auf einen anderen Planeten auslagern, dann sind Deine Daten sogar vor globalen Problemen weitgehend sicher.  😁

 

Im Ernst: klar, auch ich habe (viele) Daten, die mir lieb und teuer sind, aber selbst wenn ein Blitz eines meiner Systeme in Rauch aufgehen läßt, ist das Meiste dessen, was ich dort habe (hatte), dann eben im Backup. Ja, dann habe ich zwar einen Haufen Elektroschrott (und mein Bankkonto und ich werden jämmerlich weinen) und die aktuellen Daten, die nicht in einem Backup sind sind auch futsch. Aber so ärgerlich das ist, die gesicherten Daten sind aber dann noch da.

ECC oder Raid-pools in der verkokelten Hardware helfen da aber dann nicht und treiben nur den Preis hoch.

 

Klar, bei einem neuen System sollte man es auf Herz und Nieren zuerst stressen und testen, aber dann kann man davon ausgehen, daß es erst einmal laufen wird. (Ich habe mich bei meinem ECC Xeon System anfangs mit massiven Problem rumgeplagt, bis ich einen defekten ECC-RAM Riegel gefunden habe. ECC ist also kein Allheilmittel!)

 

Edited Friday at 11:35 PM by DataCollector
Typos