Beiträge von Crazyjoe

Neues von der Bitrot-Creators-Factory

Also ich kann nun Bitrots auf den ReFS formatierten HDDs erzeugen.

Leider hat der DiskEditor unter Windows nicht funktioniert (hängt wohl mit irgendwelchen Zugriffsrechten zusammen).
Deshalb habe mir ein Linux Mint auf den USB-Stick installiert.
Hier installiere ich den DiskEditor Active@DiskEditor. Übrigens ein sehr schönes Tool.

Nun suche ich nach dem Inhalt meiner Testdatei.txt.
Der Sektor wird entsprechend im DiskEditor angezeigt. Hebt man noch den Schreibschutz auf, dann kann man ein Byte ändern und auf der Festplatte die Änderung speichern.

In dem Mirror-Verbund der beiden Festplatten, gibt es nun also unterschiedliche Zustände der Dateien. Auf einer Festplatte ist jetzt ein Prüfsummenfehler vorhanden.
Starte ich nun Windows läuft alles völlig unspektakulär ab.

Ich überprüfe, dann zunächst mit der Windows-Version des DiskEditor, ob der Bitrot auf der Festplatte vorhanden ist. Check ... er ist drauf.

Dann rufe ich die Testdatei.txt mit dem Editor auf. Alles lesbar, keine Fehlermeldung. Der ursprüngliche Zustand wird angezeigt.
Aber im Hintergrund wurde die Datei repariert!
Wenn ich nun mit dem DiskEditor mir nocheinmal die Sektoren anschaue, dann ist wieder zweimal der gleiche Inhalt zu sehen.
Der Fehler wurde also erkannt und vollautomatisch korrigiert.

Das selbe habe ich auch überprüft, in dem ich nur die Eigenschaften der Testdatei abgefragt habe. Auch danach ist der Bitrot korrigiert.

Mein Fazit: ReFS repariert sich selbst und der Mechnismus funktioniert. Windows10Pro for Workstation reicht hier völlig. Allerdings darf man nicht vergessen die IntegrityStreams zu aktivieren!

Nun habe ich einen Mirror-Pool mit zwei Festplatten erstellt.
Die Festplatten sind in einem "Speicherplatz" als Laufwerk Z:\ im System zu sehen. Dateisystem ReFS.

Beim der Erstellung eines Bitrots habe ich allerdings ein Problem.
In der Datenträgerverwaltung sind die einzelnen Festplatten als Datenträger nicht mehr zu sehen.
Anstatt dessen ist ein neuer Datenträger zu sehen, der den Verbund der Festplatten darstellt.
Soweit ist denke ich alles normal.

Mit dem Diskeditor kann zwar ich zwar die einzelnen Festplatten sehen. Ich kann auch den Sektor finden der meine Testdatei enthält, den ich verändern möchte. Aber beim Abspeichern des Sektors bekomme ich einen "Systemfehler. Code:5 Zugriff verweigert" vom Diskeditor.

Irgendwie klappt das nicht. Ich vermute, dass Windows den Speicherpool irgendwie schützt.
Hat mir jemand einen Tipp, wie ich den Bitrot erzeugen kann?

Mit einem Linux-System booten und die Festplatte bearbeiten? Gibt es da einen Diskeditor oder Tools die zu empfehlen sind.

Zitat von SkyBird1980

Edit: Natürlich gibts auch eine Wiederherstellungsfunktion bei ReFS, aber okay. ;p

soweit bin ich noch nicht ... momentan wollte ich erst einmal ausprobieren, ob und wie ich an eine korrupte Datei herankomme.
Ich habe nämlich gelesen, dass die korrupten Datei gelöscht werden.
Das scheint aber nicht der Fall zu sein. Nur der Zugriff auf die Datei wird unterbunden. Und man kann wohl auf verschiedene Arten auch manuell eingreifen. Die automatische Reparatur funktioniert nur bei StorageSpaces mit Redundanzen.

Zitat von te36

Aber wenn die Datei jetzt eine Mediendatei waere, und du da nachgucken wolltest ob die noch "geniessbar" ist. Wie machst Du das dann bei ReFS ?

bin gerade dabei und habe folgendes herausgefunden:

Wenn man den IntegrityStream (also die Prüfsummenerkennung) für die korrupte Datei wieder deaktiviert, dann kann man wie gewohnt auf die Datei zugreifen. Dann könnte man z.B. die Mediendatei prüfen und nachschauen ob diese noch abspielbar ist.

In meinem Fall habe ich in der Testdatei.txt nur eine Jahreszahl geändert. Deaktiviere ich die Prüfsummenerkennung, dann kann ich die Datei wieder mit dem Editor öffnen und beschreiben. Ich habe ja keine defekte Festplatte, sondern den Fehler nur simuliert (durch die Änderung des Bytes mit dem DiskEditor).

Und noch weiter:
Wenn ich jetzt die Prüfsummenerkennung wieder aktiviere, dann wird die Prüfsumme neu berechnet und für ReFS ist die Datei wieder ok.

In der Powershell gibt es auch noch den Befehl repair-fileintegrity.
Den habe ich auch versucht auf die Datei anzuwenden, aber Windows spuckt die Fehlermeldung aus, dass keine Redundanz vorhanden ist.
Dies ist ja auch vollkommen richtig. Man sollte ReFS ja auch immer mit Speicherplätzen (StorageSpaces) verwenden. Wenn ich mal den Mirror unter den Speicherplätzen eingerichtet habe, werde ich das auch ausprobieren.

Übrigens: Die ganzen fehlerhaften Zugriffe werden im Ereignisprotokoll aufgelistet. Unter Quelle steht ReFS. Man kann also auch dort reinschauen und sieht welche Dateien von einem Prüfsummenfehler betroffen sind.

Es gibt neue Erkenntnisse zu ReFS. Ich war heute morgen aktiv und habe ein paar Tests gemacht.

Ich habe zwei zusätzliche Festplatten in meinen PC mit Windows10Pro for Workstation eingebaut.
X:\ mit NTFS
Y:\ mit ReFS
Auf jedem Laufwerk habe ich eine Testdatei.txt angelegt und mit dem Tool WinMD5Free die Prüfsummen ermittelt.

Dann habe ich mit einem DiskEditor die Dateiinhalte der beiden Testdateien an einer einzigen Stelle um ein Byte geändert. Das simuliert quasi einen Bitrot.
Das Dateisystem hat von dieser Änderung nichts mitbekommen. Das sehe ich daran, dass sich das Änderungsdatum der Datei nicht geändert hat.

Bemerkung: Ich hatte am Anfang einen HexEditor eingesetzt, der auf Dateiebene arbeitete. Dadurch hat dann das Dateisystem die Änderung mitbekommen. Deshalb habe ich den DiskEditor verwendet, der direkt auf die Sektoren der Festplatten schreibt und das Dateisystem umgeht.

Die MD5 Prüfsummen der Dateien haben sich, wie zu erwarten war, auch geändert. Beide Dateien konnte ich im Editor wieder öffnen.
Beide Dateisysteme NTFS und ReFS haben den Bitrot nicht erkannt.

Erstmal überlegt: Warum kann ReFS den Bitrot nicht erkannt? Achso, da war die Sache mit dem IntegrityStream, der standardmäßig deaktiviert ist.

Ich habe die Änderungen auf der ReFS rückgängig gemacht und den IntegrityStream aktiviert:
-->set-fileintegrity y:\Testdatei.txt -enable $True

Jetzt habe die Änderung mit dem DiskEditor wieder gemacht.
Die Datei war im Datei-Explorer nach wie vor zu sehen. Das Änderungsdatum hat sich nicht geändert.
Aber: Beim Versuch die Datei zu Öffnen kommt jetzt eine Fehlermeldung: "Die Datei Testdatei.txt kann nicht geöffnet werden"
Die Datei wird also von Windows jetzt als fehlerhaft erkannt und ein Zugriff nicht mehr zugelassen.
Auch ein Kopieren der Datei geht nicht mehr. Hier kommt ein Hinweis, dass ein Fehler in der Prüfsumme und Dateiintegrität vorliegt.

So wie das aussieht funktioniert die Bitrot-Erkennung mit ReFS.

Da ReFS nur auf einer einfachen Festplatte ist, kann natürlich keine automatische Fehlerkorrektur erfolgen.
Das werde ich im nächsten Schritt ausprobieren.
Aber: Das Dateisystem ReFS merkt auf jeden Fall die korrupte Datei und zeigt diese an.

Vielen Dank für die regen Kommentare

Zitat von darkside40

Hier mal ein schönes Beispiel wo in einem Bild ca. 1000 bits verändert werden und es keinen (sichtbaren) Unterschied macht:

Tja, es kommt halt immer drauf was es im Bild erwischt. Von meinen 6 Dateien, die korrupt waren, waren zwei Bilder dabei.
Einem Bild habe ich nichts angesehen und das andere war im oberen Teil ca. 10% sichtbar ok und dann nur noch grau, also unbrauchbar.

Für einen Datenserver habe ich mir auch schon TrueNAS aufgesetzt und ein wenig ausprobiert. TrueNAS mit ZFS finde ich für diese Anwendung wirklich auch toll mit den ganzen Features. Allerdings kommt ein weiteres Gerät hinzu, das auch permanent laufen muss und Strom braucht. Außerdem kommt hinzu, das ganze auch sauber zu verwalten und im Notfall auch das Richtige zu tun. Ohne Terminalbefehle, sprich Kenntnisse und KnowHow, geht das sonst auch nicht.

Auf meinem bisherigen Windows-Server läuft auch noch der DVBViewer und der DVBMediaServer als Aufnahmerecorder. Und das sehr zuverlässig und gut. Das fesselt mich eben auch an die Windows-Welt.

Somit wäre ReFS doch wirklich eine gute Lösung. Ist doch super: Datenintegrität on the fly.
Bei einem StorageSpace, würde ich alles nur mit Mirrors machen, gibts dann eine automatische Reparatur der korrupten Dateien.
Warum soll ich mich darum kümmern, wenn es das System in Echtzeit kann.

Mit SnapRaid habe ich da doch immer eine Lücke, bzw. muss ich das Scrubben regelmäßig durchführen. Macht man das bei >10TB?

Die Frage ist eben, ob das ReFS wirklich in der Praxis so gut funktioniert, wie das Microsoft verspricht.
Erst wenn ich weiß, ob und wie zuverlässig das ganze funktioniert kann ich entscheiden, ob ich es auch einsetzen möchte.
Insbesondere bei Windows 10 Pro for Workstation habe ich von diesen kritischen Berichten bzw. von diesen schlechten Erfahrungen gelesen.

Ich versuche eben den Weg der bitteren Erfahrung etwas abzukürzen und frage deshalb mal hier nach:)

Zitat von Cineologe

Mehr muss man eigentlich nicht sagen und wer seine Daten auf einem "Server" unter NTFS sichert ist naiv.

... 2014 dachte ich eben, dass es eine gute Idee ist einen Adaptec Raid Controller einzubauen und ein RAID6 darauf zu betreiben.
Aber ja, du hast sicherlich Recht wenn man meint, dass NTFS zuverlässig ist. Deshalb ja ein Dateisystemwechsel. Man lernt ja dazu:)

Das Problem an ZFS ist, dass man die Windows-Welt und die ZFS-Welt eben nicht so einfach unter einem Server zusammenbekommt.
Und dann hat man auf einmal 2 Server. Auch nicht cool.

Deshalb wollte ich eben mit ReFS einsteigen ... ohne dabei gleich in die große Windows Server Welt einzusteigen.
Ich brauch ja keine Domäne zu Hause ... ich habe ein Heimnetzwerk.

Ich brauche ein Dateisystem mit Datenintegriät!! Ist es ReFS??

Kurze Vorgeschichte:
Ich mache meine Backups immer mit FreeFileSync. Dabei synchronisiere ich immer mit der Option Datum und Dateigröße.
Von meinem Office PC (Win10Pro, NTFS) sichere ich auf meinen Server (Win10Pro, NTFS, ca. 12TB Datenbestand).
Den Server sichere ich dann ca. 4x im Jahr auf ein QNAP-NAS(ext4).

Letzte Woche kam ich auf die Idee den Sync (Office-PC auf Server) mit Dateninhalt durchzuführen. Hierbei wird also die Datei bitgenau kontrolliert.
Bei 12TB Datenbestand läuft das dann eine ganze Weile.
6 Dateien waren danach verschieden. Bitte was!?

Die Dateien hatten das gleiche Änderungsdatum und Größe, aber der Dateiinhalt war unterschiedlich!
Dann habe ich den Vergleich mit dem Backup gemacht und ebenfalls 6 Dateien identifiziert die unterschiedlich waren.

CHKDSK entdeckte auf dem Office-PC mit NTFS auf dem Server mit NTFS keine Fehler! Alles war ok.
Ich bin zu dem Ergebnis gekommen, dass auf meinem Server die 6 Dateien aus irgendeinem Grund (Bitrot?!) korrupt waren.
Da auch ein JPG-Bild dabei, das auf dem Server einfach nur grau dargestellt wurde, bestätigt meine Vermutung.
Die Dateien auf dem Server waren zwar vorhanden, aber der Inhalt Schrott. Beim Sichern auf den Server und auch beim Backup des Server bekam ich keine Fehlermeldung!

Dass ich den Fehler über das Dateisystem nicht bemerkte liegt wohl an NTFS. NTFS hat keine Checksummen … sprich Datenintegrität und weiß somit nicht, wann es einen Quatsch zurückliefert.

Deshalb dachte ich es ist gut mal ReFS auszuprobieren.

ReFS die Wunderwaffe : Datenintegrität, Checksummen, Skalierbarkeit…. usw. Also ein ganz tolles Dateisystem nach Mircrosofts Angaben.

Um Festplatten mit ReFS zu formatieren braucht man allerdings mindestens Win10Pro for Workstation oder Windows Server ab 2012.
Mit Win10Pro geht das nicht mehr (ging wohl mal bis V1709).
Also habe ich in den sauren Apfel gebissen und mir eine Win10Pro for Workstation Lizenz geholt.

Dann habe ich eine Festplatte mit ReFS formatiert. Hat alles gut geklappt.
ReFS ist drauf. Jetzt bin ich toll abgesichert. Denkste!

Nach weiterem Einlesen habe ich festgestellt, dass man den sogenannten IntegrityStream aktivieren muss, dass die Checksummenberechnung auch für die Datendateien durchgeführt wird.
Ansonsten ist kann auch hier kein Bitrot erkannt werden.

Wo man den Integrity-Stream aktivieren? Achso, ganz „komfortabel“ über die Powershell mit dem cmdlet set-integrityfile … alles klar (!), muss man ja nur Wissen.
Ich möchte nicht wissen, wie viele Leute das nicht aktiviert haben und der Meinung sind, dass sie ein sichereres Dateisystem haben.

Dann habe ich gelesen , dass die Fehlererkennung bei Windows 10 Pro for Workstation nicht funktionieren soll?
Bei Windows Server 2016/19 wohl kein Problem, aber mit Windows 10 Pro for Workstation soll es hier Probleme geben.
Siehe hier: https://social.technet.microsoft.com/Forums/windows…l&prof=required

Nun bin ich etwas verwirrt . Ist ReFS nun mit Windows 10 Pro for Workstation sicher lauffähig?
Kann mir hierzu jemand was sagen?
Auch allgemeine Erfahrung zu ReFS würden mich interessieren.
Wie gut funktioniert das ReFS mit Win10Pro for Workstation?

Ich würde das ganze Szenario eines Bitrots mal durchspielen und schauen, ob ich mit ReFS die Dateien retten kann.
Wie kann ich das ausprobieren? Geht das mit einem Hex-Editor? Hat mir jemand einen Tipp.

Grüße
Joe

Zitat von JoGi65

Soweit ich mich erinnere, ist die VGA Funktion Onboard. Das heißt, du brauchst keinen Prozessor mit Grafik. Braucht nur Leistung.

Da bin ich mir auch noch unsicher. Ich habe das so gelesen, dass die Onboard VGA Funktion auch nur am VGA rauskommt und diese Grafikeinheit nur für den IPMI-Betrieb ist.
Aber sicher weiß ich das nicht. Weiß das jemand?

Zitat von JoGi65

Selbst wenn dem nicht so ist, ich hab seit einigen Jahren 3 Server im Keller, da war noch nie ein Bildschirm dran, soweit ich mich erinnere. Das geht alles über IPMI.

Genau so habe ich mir das vorgestellt. Ist doch eine tolle Sache.
Dazu braucht man dann nur noch das richtige Powermanagement auf der Kiste. Also ich meine, dass sich der Server per WOL wecken lässt und dass er solange anbleibt wie er benötigt wird. Ich habe auf meinem bisherigen Server (Win10) ein Programm namens SmartPower drauf. Das überprüft dann z.B. ob mein HTPC an ist und schaltet so dann nicht aus.
Wie das allerdings unter TrueNAS zu realisieren ist weiß ich noch nicht.

Den Beitrag "Neuer Multiserver/Datenspeicher" schau ich mir auch noch an. Danke.

Zitat von te36

Aber wieviele platten willst Du maximal einbauen koennen ? Wenn das mehr als 8 sind brauchst Du noch einen HBA zusaetzlich.

nicht mehr als 8. Ich möchte mir neue 8/10/12TB-Platten kaufen. Da habe ich schon ein paar in engerer Auswahl, nein ... kein WD RED Plus/Pro ... da gibts bessere für weniger Geld.
Besser heißt MTBF 2Mio und Fehlerrate eine 10er-Potenz besser also bei 10^15!
z.B. WD UltraStar HC300-Serie oder HC500-Serie, sowie Seagate EXOS X16-Serie
--> alles Enterprise Platten für NAS

Vorerst würde ich mal 4 einbauen und diese mit ZFS in einem Pool laufen lassen. Dabei würde ich 2 vDevs machen, wobei jede vDev ein Mirror ist. Ist dann quasi ein RAID10.
Bei 4x10TB habe ich also 20TB netto zur Verfügung.
Bei einer Erweiterung könnte ich dann einen weiteren Mirror in den Pool. Dann 30TB ... usw. Und das kann auch erst in einem Jahr machen:)
Und bei 10TB müssen 8 Ports reichen!

Zitat von te36

Ich habe ja einen 2308i, und da wurde ja auch in dem Video clip auf den hoeheren Stromverbrauch hingewiesen. Bei mir lief der mit 95 grad C bevor ich einen noctua luefter draufgeklemmt habe.

Ok ... Wärmeentwicklung. Das habe ich auch schon gelesen. Ich werde mal die Onboard SATA-Port des Supermicros MB ausprobieren. Dann spare ich mir das Geld für den LSI-Controller. Außerdem die Firmwareaktualisierung... da habt ihr recht. Ich glaube nicht, dass ich dadurch Performance gewinne.
Und was keine Wärme macht muss auch nicht gekühlt werden.

Zitat von te36

IT-Firmware scheint es fuer 9211 zu geben, aber lies das lieber nochmal nach.

ja gibt hier bei Broadcom.
Der große Trick dabei ist, und ich habe ewig gesucht bis ich das herausgefunden habe, dass man bei
ProductGroup "Legacy Products"
Product Family "Legacy Host Bus Adapters"
eingibt.

Jetzt kann man bei ProductName die alten Controller aussuchen. Dann mit "search" abschicken.
Dann bekommt man alles für das Produkt: Firmware, Dokus, Datenblätter

Zitat von JoGi65

Da Du dich schon so gut in die Dateisysteme einliest, kannst Du dir ja auch noch ReFS mit Speicherpools (Edit: Storage Space) anschauen. Ich denke das geht bei Win 10 pro mittlerweile auch. Wenn ich mich richtig erinnere ist das fast so Safe wie ZFS.

ReFS und Win10 Pro habe ich probiert. Geht nicht. Dazu brauchts du "Win10 Pro for Workstations".
Ich habe das so verstanden, dass Win10 Pro ReFS zwar lesen kann, aber keine Festplatte mit ReFS formatieren oder einen Speicherpools einrichten kann.

Und Win10 Pro for Workstation kostet ca. 250€ ... Link

Ein Update bei Microsoft ist auch nicht billig. Da langt Mircrosoft voll zu ....

Zitat von JoGi65

Falls Du nicht den Xeon einsetzt, schau noch ob der I3 alle Mainboard Funktionen unterstützt. Ich habe da irgendwas vom IPMI bzw. ECC im Hinterkopf. Aber ist schon wieder (zu) lange her.

Danke, guter Hinweis muss ich mal recherchieren...

Ich habe grundlegend die Sache überdacht und bin zu folgenden Entschluss gekommen:

Mein Win10 mit dem Adaptec RAID6 ist veraltet und ist mir nicht ausreichend sicher.
Angefangen von dem Win10 mit NTFS. Ich dachte immer NTFS ist fortschrittlich, aber es ist ein in die Jahre gekommenes Dateisystem.

Deshalb möchte ich diesen Server, der momentan mein TV-Server (4xSAT+Aufnahmegerät) und zudem Medien- und Dateiserver ist, neu aufbauen.
Dabei bin ich auf die Idee gekommen, den alten Server erstmal weiter laufen zu lassen. Dann habe ich mal keinen Stress. Ein paar Wochen wird der schon noch durchhalten.

Der neue Server soll dabei nur ein Dateiserver werden.
Er soll meine ganzen Medien (Filme, Bilder, Musik...), Dateien (Office-Dateien) und Backups (Images, Einzelsicherungen) im Original speichern.

Als Dateisystem möchte ich BTRFS oder ZFS nehmen.
Da mir BTRFS noch nicht ganz ausgereift erscheint, möchte ich ZFS verwenden.
Als NAS-OS kommt dann TrueNAS zum Einsatz.

Als Mainboard habe ich mir das Supermicro X11SCA-F ausgesucht.
Dieses Mainboard hat bereits 8xSATA. Es kann auch RAID 0/1/5/10. Den RAID-Controller benötige ich nicht.

Deshalb meine Frage:
Ist es besser einen HBA-Adapter, z.B. LSI9211-8i (NP: ca. 180€), zu verwenden oder sind die 8xSATA onboard voll ok?

Ich denke mal, dass ich den RAID-Controller auf dem MB deaktivieren kann und die SATA-Ports dann im Pass-Through laufen.
Funktioniert das so? Hat jemand so ein Mainboard im Einsatz?

Ansonsten wäre das Mainboard mit ca. 280€ gar nicht mal so teuer, wenn man für einen HBA LSI9211-8i ca. 180€ rechnet.
Dazu kommt dann noch ECC-Speicher und ein i3-9100 (ca. 120€) oder ein XEON E-2224G (ca. 230€).
Mit dem IPMI (Remote-Zugriff) auf dem Mainboard, könnte ich den Server dann bequem in den Keller stellen und per Remote bedienen.

Hört sich ganz gut an.
Aber an einem Backup kommt man nie vorbei und das läuft bei dir in die Cloud. Auch ne Idee.
Was hast du da für einen Anbieter?

Deine 10 Platten laufen auf einen Ubuntu 18.04 ... Serverversion oder Standard?
Dort hast du unionfs und SnapRAID drauf. Habe ich das korrekt interpretiert?

ok. Und wieviele Platten mit Paritäten hast du ? 2?

Die Skalierbarkeit bei SnapRAID ist genial gelöst. Hier gibts nichts zu meckern:)

SnapRAID hat ja auch eine eingebaute Datenintegrität. Steht auf der Compare-Seite von SnapRAID.
Diese soll mit Prüfsummen funktionieren. Aber wie funktioniert die genau?

Wann wird die Prüfsumme einer Datei erstellt und wo abgelegt?
Ich meine, wenn man auf die Platten schreibt geht das direkt über ext4 auf die Platte.
Zu diesem Zeitpunkt werden noch keine Prüfsummen angelegt. ext4 kann das ja nicht.

Erst beim Erstellen der Parity werden die Prüfsummen berechnet und werden vermutlich auf der Parity-Platte mit abgelegt.
Hier dürfen natürliche keine Speicherfehler stattfinden. Deshalb dachte ich, dass ECC-RAM sinnvoll ist.

SnapRAID kann jetzt beim Überprüfen den Festplatteninhalt mit den Prüfsummen überprüfen. Deshalb hat man hier eine zusätzliche Sicherheit.

Aber: Zufällige Lesefehler beim Zugriff auf die Platte können nicht erkannt werden können. Es wird ja nicht bei jedem Lesevorgang auch die Prüfsumme der Parityplatte gecheckt.

Das bedeutet dann:
Nehmen wir weiter an, dass sich ein Bit auf der Festplatte dauerhaft ändert (z.B. durch einen defekten Sektorbereich).
Das könnte SnapRAID nur durch eine Syncvorgang über die Prüfsummen reparieren.
Vorteil: Man kann reparieren
Nachteil: nicht in Echtzeit

Wenn allerdings das defekte Bit auf der Prüfsummenfestplatte ist, dann hat man auch wieder Pech. Was SnapRAID dann macht ist mir unklar, da SnapRAID nicht weiß wo der Fehler ist.

Fazit: SnapRAID gibt zusätzliche Sicherheit, aber auch nur eingeschränkt.

Zu dem Thema zusammenhängendes Laufwerk: Möglichkeiten mit AUFS und MergeFS.
Habe ich noch nie ausprobiert, sondern nur davon gelesen, deshalb vielleicht die Anfängerfragen hierzu.

Bleiben wir mal bei meinem Beispiel von 6 Daten-Volumes HDDs und 2 HDDs für die Parity.
Ich fasse meine 6 Volumes zu einem "BigVolume" zusammen.

Nehmen wir weiter an ich kopiere mein z.B. 4TB Videoarchiv, 2TB Musikarchiv und das 3TB Bildarchiv auf mein "BigVolume".
Anschließend kommen dann nach und nach die verschiedensten Dateien hinzu. Ich speichere diese natürlich wieder in die entsprechenden Ordner. Aber auf den Platten wird das alles mehr oder weniger auf alle Festplatten verteilt. Oder wie sieht das in der Praxis aus?

SnapRAID arbeitet im Hintergrund einen Layer weiter unten und macht bei Bedarf (zeitgesteuert oder manuell) die Snaps und berechnet die Paritys und legt diese auf den Paritätsplatten ab. Ist aber nicht in Echtzeit, sondern bedeutet die Paritätsberechnung läuft im Nachhinein. Richtig?

Zitat von JoGi65

Nicht vergessen, dass TrueNAS mit ZFS auch ECC Ram möchte. (Board,Proz.)

Ja, aber bei SnapRAID sollte man auch ECC RAM haben! Hier wird auch die Parität im RAM berechnet. Irgendwo auf den SnapRAID-Seiten habe ich gelesen, dass man den Speicher auf jeden Fall mit mem86+ testen soll.

Zitat von JoGi65

Wundert mich. Waren das alles große Dateien? Einbrechen tut TrueNAS nur mit kleinen. Da ist es nicht gut.

ne, war eine große 4GB Datei. Lokal von SSD auf den Pool kopiert.

Zitat von JoGi65

Beim Erweitern ist es am besten den Pool neu aufzubauen. Das bedingt allerdings eine "sichere" Sicherung zum rückspielen.
Hab meine ca. 18TB? schon mehmals hin und her geschoben wegen Plattentausch bzw. Plattengrößen Umstieg.

Respekt. Geht natürlich auch, aber Spaß ist anders:)

Wenn ich ein ZFS Volume auf jeder Platte mache, dann habe ich einzelne Laufwerke und kein zusammenhängendes Laufwerk.

Beispiel: Wenn ich 8x3TB mit SnapRAID (Parität 2) betreibe. Dann hätte ich 6 Laufwerke, die ich mit Samba freigeben muss. Richtig?

Zitat von te36

Womit ?

Ganz einfach und simpel: Mit einem externen USB-Festplattengehäuse in das ich nacheinander mehrere Festplatten eingebaut habe. Einfach mit Windows draufkopiert.

Ich habe vor ein paar Wochen auch mit TrueNAS experimentiert. FreeNAS gibt es ja jetzt nicht mehr. Ich habe TrueNAS V12.0 installiert und mir ein Pool mit RAID-Z1 mit 3x3TB eingerichtet. Hab mir auch ein paar Videos anschauen müssen...

Das System war mit meinem in die Jahre gekommenen i5-760 nicht ganz so leistungsfähig. Habe das NAS mit 70-80MB/s beschreiben können. Deshalb habe ich es wieder verworfen.
Bei OMV mit einem Test-RAID 5 waren es 100-110MB/s, was das max. bei meinem 1Gb-Netzwerk ist. Und die Bedienung von OMV ist sehr intuitiv. Bei TrueNAS gibts da schon ein paar Stolperfallen.

Mit den jetzigen Kenntnissen gewinnt TrueNAS aber wieder an Attraktivität.

Was mir bei ZFS nicht gefallen hat, war auch die Tatsache der Erweiterungmöglichkeiten.

Nehmen wir an ich richte einen Pool (so nennt sich das in ZFS) mit einem RAID-Z1 mit 4x3TB ein. Das entspricht einem RAID5 (also einfache Redundanz).
Dem vorhandenen Pool kann ich jetzt aber nicht nur eine weitere Festplatte hinzufügen. Man könnte das schon machen, aber dann wäre die Redundanz des gesamten Pools weg.
Wenn dann die neue Festplatte den Geist aufgibt, zieht sie den gesamten Pool mit in den Abgrund. Dann wäre alles weg!! Ist dann so wie wenn ein RAID abschmiert.

Was gehen würde: Dem Pool ein weiteres RAID-Z1 mit weiteren 4x3TB (oder 3x3TB) Platten hinzufügen. Der Pool besteht dann aus 2 RAID-Z1-Verbünden.
Aber ein vorhandenes RAID-Z1 um eine Festplatte erweitern ist nicht möglich (zumindest habe ich das so verstanden). Das fand ich nicht optimal.

Vielen Dank für deine Antworten:) Die Lernkurve geht steil nach oben ...

Tja, so langsam wird mir einiges klar. Ich hatte vor einem halben Jahr auf meinem RAID6 (Adaptec 71605 unter Windows, also NTFS) einen Fehler im Dateisystem. Habe ich zufällig gemerkt. CHKDSK hat mir dann Fehler angezeigt.
Und ich habe mich noch gefragt, was jetzt los ist.
Das erstaunliche war, dass der Adaptec Storage Manager bei dem RAID6 keinen Fehler gemeldet hat. Auch RAID-Integritätstest war fehlerlos.
Das könnte durchaus so schleichender unerkannter Lesefehler gewesen sein.

Ich habe dann gleich ein Backup auf externe Festplatten gemacht. Das ist auch der Grund warum ich mir jetzt so einen Backup-Container (Backup-NAS) aufbauen möchte.
Dann habe ich mit CHKDSK den Fehler repariert. Was dabei aber alles passiert weiß ich nicht? Auf jeden Fall ist mir bisher nichts aufgefallen und alles ist gut. Denke ich:)

NTFS hat keine Prüfsummen, die einen schleichenden Fehler erkennen. Mist!!
Ich habe Windows am Start da ich den DVBViewer mit 4 SATs am Laufen habe. DVBViewer läuft ja nur unter Windows.

Ich glaube ich muss auch meinen Server überdenken. Hmmm.

Das Zauberwort heißt Prüfsummen in Echtzeit, die einen Fehler erkennen können.

ext4 als Dateisystem finde ich dann auch nicht so genial.

Wenn man die zufälligen Lesefehler im Betrieb in Echtzeit erkennen möchte bleibt eigentlich nur ZFS oder Btrfs übrig. Oder?

Zitat von te36

Die Daten auf der Festplatte sind mit Fehlerkorrektur versehen. Bei neueren Festplatten kann man das sogar sehen, z.b. counter fuer "Hardware_ECC_recovered".

Das sind dann Lesefehler, die die Festplatte erkennt. Was meinst du mit Counter für "Hardware_ECC_recovered". Ist das ein S.M.A.R.T.-Wert der Festplatte?

Zufällige Lesefehler (das sind die, die mit 1x10¹⁴ auftreten) können verschiedene Auswirkungen haben.
Fakt ist, dass diese Fehler nicht von der Festplatte entdeckt werden und ans OS weitergegeben werden.

Tritt beim Abpsielen eines Videos ein zufälliger Leserfehler so entsteht (wie du oben auch schon erwähnt hast) ein kleiner unbedeutender Bildfehler.
Tritt er beim Laden eines Programms auf kann es sein, dass Programm nicht sauber funktioniert oder abstürzt.
Bei einem falsch geladenen Treiber gibts vielleicht ein Absturz oder BlueScreen.

Tritt der Lesefehler beim Kopieren auf, dann wird die Datei mit dem Fehler kopiert ohne dass man das merkt!! Ist das so richtig beschrieben?

Oder würde so ein zufälliger Lesefehler durch die Metadaten des ext4 erkannt werden?

Oder kann das nur ZFS und Btrfs?