Homeserver - Festplatten und OS?

T...Was aber vor allem an der Performance lag, der kleine Celeron J ist wegen jeder Kleinigkeit auf 100% Last gelaufen...

liegt unter umständen an der baytrail atom architektur die aufgaben nacheinander abarbeitet oder halt an win10. unter win10 hab ich da noch keine erfahrungen drauf sammeln können da die kiste nur einmal für 2 minuten win10 gesehn hat um die digitale lizenz auf das board zu bügeln.
mein j1900 dümpelt unter win7 mit 2 vms (xpenologie und entertain) rum, nur wenn win7 mal wieder meint updaten zu müssen oder der avscan ansteht dreht der kleine durch. dafür aber auch deutlich unter 20w mit den festplatten.


da ich aber auf windows storages spaces will, muss ich mich wohl bald von win7 verabschieden, oder ich wechsel zu was anderem. daher bin ich gerade am rumtesten ob freenas oder omv, da eine vm xpenologie beheimatet. der windowshost ist halt nurnoch da weil der server vor jahren mal aufgesetzt wurde , war halt einfach und alles lief ootb, auch ts und mc server. die sind jetzt weg und geht nur noch um die nasfunktion bei möglichst wenig stromverbrauch, daher halte ich auch an dem j1900 oder an einem nachfolger fest, gerade auch weil die boards 4 sataports haben.
 
Möglich…wobei ich mich auch selbst über die schlechte Performance gewundert habe. Gibt ja schließlich auch Laptops/Netbooks, mit den Celerons als Basis, die laut diversen Tests funktionieren.
Hab mich dann aber auch nicht mehr näher mit dem Problem beschäftigt, da Docker unter Windows auch nicht wie gewünscht gelaufen ist -> zurück zu Debian.
 
Sorry, aber ein reiner RAID5 ist Unsinn. Die Wahrscheinlichkeit bei einem Rebuild eine zweite Platte bei >4TB zu verlieren ist fast 100%. Und dann sind alle Daten weg. Bei einer Platte als Parität brauchst du irgendetwas was Checksummen berechnet - sei es ZFSZ1 oder ein Software-"Raid" wie unRAID oder Snapraid.
Warum ist die Wahrscheinlichkeit für einen Ausfall bei einem Rebuild höher, und warum gerade bei über 4 TB? Kannst du mir das nochmal erklären?

Wenn du Angst vor dem Ausfall einer Platte um Sinne der Hochverfügbarkeit hast - nimm ein RAID1 (wenn Daten unterbrechungsfrei verfügbar sein müssen). Kannst du dir Downtime erlauben - lass sie einzeln laufen (man kann auch einzelne Platten als RAID1 anlegen) und mache mit der zweiten Platte ein versioniertes Backup.
Willst du viele Platten zu einer "großen" zusammenfassen, nimm unter Linux etwas wie auFS oder mergerFS. Zusammen mit mit Snapraid super.
Nee, Downtime ist überhaupt kein Problem. Also eher eine große 8TB-Platte oder JBOD?
Das hier sieht eigentlich sehr gut aus: https://www.technikaffe.de/anleitung-242-snapraid_und_aufs_unter_openmediavault_als_raid_5_6_ersatz

Verliere ich mit Snapraid eigentlich viel Geschwindigkeit? Ich bin da etwas "geschädigt" von einem Software-RAID 1 unter Mac OS auf zwei USB-HDDs, das nicht nur ständig defekt, sondern auch schnarchlahm war...

Wie meinst du das mit einzelnen Platten als RAID 1?

Ahhhhh jaaaa..... f*** hätte da nen Schlaganfall. Raid5 ist wirklich ungünstig. Es gab doch ein raid 0 mit einer einzelnen Festplatte als Spiegelung als Backup... was war das nochmal?
Das hatte ich mir ursprünglich ja auch überlegt (allerdings mit manuellem Backup), aber RAID 0 scheint ja nicht so beliebt zu sein ;)

mein j1900 dümpelt unter win7 mit 2 vms (xpenologie und entertain) rum, nur wenn win7 mal wieder meint updaten zu müssen oder der avscan ansteht dreht der kleine durch. dafür aber auch deutlich unter 20w mit den festplatten.
Da muss ich mal eine Lanze für den Dell T20 brechen: Knapp 20W mit 3 Festplatten :thumbup:
 
3 4TB als Raid 5 :thumbup:
Die Variante hätte ich bei den gegebenen Optionen auch gewählt.
Sorry, aber ein reiner RAID5 ist Unsinn. Die Wahrscheinlichkeit bei einem Rebuild eine zweite Platte bei >4TB zu verlieren ist fast 100%.
Das musst du mir mal erklären :confused:

Bei einer Platte als Parität brauchst du irgendetwas was Checksummen berechnet - sei es ZFSZ1 oder ein Software-"Raid" wie unRAID oder Snapraid.
Ich bin jetzt nicht so der Fan von unRAID oder Snapraid. Da empfehle ich lieber, auf standardisierte Verfahren wie RAIDZ1 von ZFS oder eben die "normalen" RAID-Level z.B. mit mdadm unter Linux zu setzen. Da hat man mehr Chancen, Dinge zu reparieren, wenn mal was schief geht. Ich spreche da aus Erfahrung ;) Und Backup braucht man ja wie gesagt sowieso.
Wenn du Angst vor dem Ausfall einer Platte um Sinne der Hochverfügbarkeit hast - nimm ein RAID1 (wenn Daten unterbrechungsfrei verfügbar sein müssen).
Wenn du ein RAID1 aus 2x 4TB HDDs nimmst, verschenkst du 50% Platz, musst zum Rebuild 4 TB lesen und 4 TB schreiben und hast 4 TB nutzbare Kapazität.
Wenn du ein RAID5 aus 3x 4TB HDDs nimmst, verschenkst du 33% Platz, musst zum Rebuild 8 TB lesen und 4 TB schreiben und hast 8 TB nutzbare Kapazität.
So viel schlimmer ist ein RAID5 jetzt auch nicht als ein RAID1 und hat eben durchaus auch seine Vorteile.
Wobei ich bei dir bin: Ich empfehle auch immer eher ein RAID6 wo es geht aufgrund des Silent-Bit-Rod (SBR). Aber dafür braucht man halt auch gleich 4 HDDs als Minimum, so richtig lohnen tut es sich dann erst bei noch mehr HDDs. Oder halt ZFS nehmen. Mit all seinen Vor- und Nachteilen. Und der Möglichkeit von ZFS RAID-Z1.

Kannst du dir Downtime erlauben - lass sie einzeln laufen (man kann auch einzelne Platten als RAID1 anlegen) und mache mit der zweiten Platte ein versioniertes Backup.
Auch durchaus eine Möglichkeit, wenn man Backup gleich mit "erschlagen" möchte.
Willst du viele Platten zu einer "großen" zusammenfassen, nimm unter Linux etwas wie auFS oder mergerFS. Zusammen mit mit Snapraid super.
Du willst ein Overlay-FS, welches für nicht-beschreibbare Datenträger gedacht ist, dafür benutzen? Das klingt abenteuerlich!

Ahhhhh jaaaa..... f*** hätte da nen Schlaganfall. Raid5 ist wirklich ungünstig. Es gab doch ein raid 0 mit einer einzelnen Festplatte als Spiegelung als Backup... was war das nochmal?
Vermutlich meinst du RAID1?
 
Ich bin jetzt nicht so der Fan von unRAID oder Snapraid. Da empfehle ich lieber, auf standardisierte Verfahren wie RAIDZ1 von ZFS oder eben die "normalen" RAID-Level z.B. mit mdadm unter Linux zu setzen. Da hat man mehr Chancen, Dinge zu reparieren, wenn mal was schief geht. Ich spreche da aus Erfahrung ;) Und Backup braucht man ja wie gesagt sowieso.
Was spricht denn gegen Snapraid? Ich hatte daran jetzt zwei Vorteile gesehen - zum einen, dass man die Dateien weiterhin normal extern auslesen kann (ein RAID lässt sich doch nur mit einem baugleichen RAID-Controller auslesen, oder?) und zum anderen, dass ich jetzt mit zwei 4TB-HDDs loslegen und das System nachher um eine dritte HDD erweitern kann, um dann Snapraid einzurichten. Letzteres Argument erledigt sich dann ja irgendwann (oder ich kaufe jetzt noch eine HDD), aber die Möglichkeit, dass die Daten extern auslesbar sind, finde ich schon praktisch. Oder geht das mit einem richtigen RAID (Software bzw. Intel RST) auch?

Wobei ich bei dir bin: Ich empfehle auch immer eher ein RAID6 wo es geht aufgrund des Silent-Bit-Rod (SBR). Aber dafür braucht man halt auch gleich 4 HDDs als Minimum, so richtig lohnen tut es sich dann erst bei noch mehr HDDs. Oder halt ZFS nehmen. Mit all seinen Vor- und Nachteilen. Und der Möglichkeit von ZFS RAID-Z1.
RAID 6 ist leider preislich wirklich nicht drin... und ZFS bringt ja dann Probleme mit externen Datenträgern (für mein regelmäßiges Backup) mit sich, wie Adun berichtet hat. Daher muss meine Entscheidung wohl zwischen Snapraid und einem RAID 5 fallen.

Du willst ein Overlay-FS, welches für nicht-beschreibbare Datenträger gedacht ist, dafür benutzen? Das klingt abenteuerlich!
Ist mergerFS nicht für solche Zwecke gedacht? Ich habe das jetzt schon oft im Zusammenhang mit OMV gefunden. Gibt es eine andere Lösung für ein "Software-JBOD"?

Noch eine Frage: An SSDs habe ich momentan eine Samsung 470 64GB, eine Intel 320 80GB (die lief bisher als Systemplatte im T20) und eine Intel 535 120GB (sowie eine Samsung 850 Evo 250GB, aber die ist ja bisschen Perlen vor die Säue, steht daher nicht wirklich zur Wahl). Von den SMART-Werten her sind alle einwandfrei, die Intel 320 hat wohl die meisten Betriebsstunden. Die Intel 535 hat als einzige SATA 3. Was würdet Ihr denn als System-SSD für OMV nehmen? Kann ich da problemlos eine der älteren SSDs verwerten?
 
Zuletzt bearbeitet:
Was spricht denn gegen Snapraid?
- Backups müssen manuell angeworfen werden
- freier Speicherplatz kann nicht insgesamt, sondern immer nur je HDD genutzt werden (doof, wenn das ganze schon relativ voll ist und man große Dateien (Disk-Image?) rüberkopieren will
- etwas unflexibel bei der Größe der Paritätsfestplatte
- eher nur für wenige große Dateien geeignet und nicht so gut für viele kleine

Ich denke, man kann SnapRAID schon einsetzen, ich persönlich bin aber kein großer Fan davon.

Ich hatte daran jetzt zwei Vorteile gesehen - zum einen, dass man die Dateien weiterhin normal extern auslesen kann (ein RAID lässt sich doch nur mit einem baugleichen RAID-Controller auslesen, oder?) und zum anderen, dass ich jetzt mit zwei 4TB-HDDs loslegen und das System nachher um eine dritte HDD erweitern kann, um dann Snapraid einzurichten. Letzteres Argument erledigt sich dann ja irgendwann (oder ich kaufe jetzt noch eine HDD), aber die Möglichkeit, dass die Daten extern auslesbar sind, finde ich schon praktisch. Oder geht das mit einem richtigen RAID (Software bzw. Intel RST) auch?
Wenn du das Standardwerkzeug von Linux für ein RAID nutzt ("mdadm"), dann kannst du die Daten überall auslesen, wo ein Linux läuft (sofern mdadm vorhanden ist) und sofern du alle zum RAID gehörenden Platten anschließt (ggf. abzüglich Parität). Auch kannst du mit mdadm das RAID nachträglich vergrößeren und ggf. sogar verkleinern, letzteres setzt aber ein kompatibles Dateisystem voraus und ist eher nicht zu empfehlen, aber nachträglich erweitern geht. Nachträglich RAID-Level ändern geht auch, also z.B. mit RAID1 anfangen, auf RAID5 wechseln und später auf RAID6 erweitern. Baugleiche Controller brauchst du dann nicht, genau genommen nimmst du überhaupt gar keinen RAID-Controller, sondern schließt die HDDs ganz normal an SATA-Controller jeder Art an.

RAID 6 ist leider preislich wirklich nicht drin... und ZFS bringt ja dann Probleme mit externen Datenträgern (für mein regelmäßiges Backup) mit sich, wie Adun berichtet hat. Daher muss meine Entscheidung wohl zwischen Snapraid und einem RAID 5 fallen.
Welche Probleme bringt ZFS genau mit sich bei der Verwendung externer HDDs?
Für mich ist der größte Nachteil von ZFS nur, dass ich nicht nachträglich RAIDs durch mehr HDDs erweitern kann, nur durch größere HDDs oder die Daten müssen einmal runter.

Ist mergerFS nicht für solche Zwecke gedacht? Ich habe das jetzt schon oft im Zusammenhang mit OMV gefunden. Gibt es eine andere Lösung für ein "Software-JBOD"?
Also Overlay-Dateisysteme sind dafür gedacht, dass eigentlich nicht beschreibbare Datenträger sich beschreiben lassen. Oder Datenträger, die nicht beschrieben werden sollen, sich beschreiben lassen.
Beispiel: Gerne macht embedded Hardware das so, dass es eine Partition mit dem gesamten System gibt, die nicht beschrieben werden soll. Darüber wird ein Overlay-Dateisystem gepackt wie halt auFS oder mergerFS. Die zeigen erst einmal genau das gleiche an wie es auf der Systempartition vorhanden ist. Schreibst du nun Änderungen, werden nur diese Änderungen weggeschrieben, aber eben nicht auf die System-Partition, sondern auf eine Extra-Partition. Wenn du nun irgendwann das Gerät zurücksetzen willst/musst, musst du nur die Partition mit dem auFS wegwerfen, die Systempartition ist ja nie verändert worden. Oder wenn das Ding nicht mehr bootet, dann mountet man einfach nur das auFS nicht und bootet von der "heilen" Systempartition.
Anderes Beispiel: Linux-Live-CD. Die CD ist nun mal nicht veränderbar und selbst wenn man sie auf einen Stick spielt, will man in der Regel nicht, dass dieser verändert/überschrieben wird. Also wird auch da so ein Overlay-FS drübergelegt, welches die Änderungen meist nur im RAM wegschreibt. Wenn du nun deine Live-CD bootest und dann z.B. ein paar Anwendungen nachinstallierst, dann bleibt die CD bzw. der Stick so wie er ist, nur die Änderungen werden in den RAM geschrieben und dank des Overlay-FS sieht die Kombination aus CD/Stick und den Änderungen im RAM für Betriebssystem und User so aus wie ein einziges Dateisystem (mit eben den Änderungen).

Daher verstehe ich noch nicht, was man damit im NAS will?
Noch eine Frage: An SSDs habe ich momentan eine Samsung 470 64GB, eine Intel 320 80GB (die lief bisher als Systemplatte im T20) und eine Intel 535 120GB (sowie eine Samsung 850 Evo 250GB, aber die ist ja bisschen Perlen vor die Säue, steht daher nicht wirklich zur Wahl). Von den SMART-Werten her sind alle einwandfrei, die Intel 320 hat wohl die meisten Betriebsstunden. Die Intel 535 hat als einzige SATA 3. Was würdet Ihr denn als System-SSD für OMV nehmen? Kann ich da problemlos eine der älteren SSDs verwerten?
Vermutlich ziemlich egal. Such' dir eine aus. Oder würfel sie aus ;)
 
- Backups müssen manuell angeworfen werden
- freier Speicherplatz kann nicht insgesamt, sondern immer nur je HDD genutzt werden (doof, wenn das ganze schon relativ voll ist und man große Dateien (Disk-Image?) rüberkopieren will
- etwas unflexibel bei der Größe der Paritätsfestplatte
- eher nur für wenige große Dateien geeignet und nicht so gut für viele kleine
Hm, okay. Punkt 1 wollte ich mit einem Cronjob Abhilfe schaffen (ein Backup pro Tag müsste reichen) und Punkt 2 mittels MergerFS, aber Punkt 4 ist natürlich doof, da der Großteil auf den HDDs ja Fotos - also ziemlich viele kleine Dateien à 25 MB - sein werden.

Wenn du das Standardwerkzeug von Linux für ein RAID nutzt ("mdadm"), dann kannst du die Daten überall auslesen, wo ein Linux läuft (sofern mdadm vorhanden ist) und sofern du alle zum RAID gehörenden Platten anschließt (ggf. abzüglich Parität). Auch kannst du mit mdadm das RAID nachträglich vergrößeren und ggf. sogar verkleinern, letzteres setzt aber ein kompatibles Dateisystem voraus und ist eher nicht zu empfehlen, aber nachträglich erweitern geht. Nachträglich RAID-Level ändern geht auch, also z.B. mit RAID1 anfangen, auf RAID5 wechseln und später auf RAID6 erweitern. Baugleiche Controller brauchst du dann nicht, genau genommen nimmst du überhaupt gar keinen RAID-Controller, sondern schließt die HDDs ganz normal an SATA-Controller jeder Art an.
Oh, das klingt natürlich super. Gingen denn folgende Szenarien? Und wie "gefährlich" wäre so ein Umbau für die Daten?
- RAID 5 einrichten mit 2x 4TB sowie 1x 3TB (= 6TB RAID 5), dann später die 3TB durch 1x 4TB ersetzen und somit das RAID auf 8TB erweitern?
- RAID 5 einrichten mit 2x 4TB sowie 2x 3TB (= 9TB RAID 5), dann später die 2x 3TB durch 1x 4TB ersetzen und das RAID auf 8TB verkleinern?

Als Dateisystem für die HDDs hätte ich jetzt einfach ext4 gewählt, spricht da etwas dagegen?

Welche Probleme bringt ZFS genau mit sich bei der Verwendung externer HDDs?
Für mich ist der größte Nachteil von ZFS nur, dass ich nicht nachträglich RAIDs durch mehr HDDs erweitern kann, nur durch größere HDDs oder die Daten müssen einmal runter.
Ich will ja regelmäßig eine USB-HDD anschließen, um ein Backup des kompletten NAS zu ziehen. Da hatte Adun auf der vorherigen Seite mit seinem FreeNAS-System mit ZFS getestet und konnte keine USB-Datenträger ohne Datenverlust mounten.

Also Overlay-Dateisysteme sind dafür gedacht, dass eigentlich nicht beschreibbare Datenträger sich beschreiben lassen. Oder Datenträger, die nicht beschrieben werden sollen, sich beschreiben lassen.
Beispiel: Gerne macht embedded Hardware das so, dass es eine Partition mit dem gesamten System gibt, die nicht beschrieben werden soll. Darüber wird ein Overlay-Dateisystem gepackt wie halt auFS oder mergerFS. Die zeigen erst einmal genau das gleiche an wie es auf der Systempartition vorhanden ist. Schreibst du nun Änderungen, werden nur diese Änderungen weggeschrieben, aber eben nicht auf die System-Partition, sondern auf eine Extra-Partition. Wenn du nun irgendwann das Gerät zurücksetzen willst/musst, musst du nur die Partition mit dem auFS wegwerfen, die Systempartition ist ja nie verändert worden. Oder wenn das Ding nicht mehr bootet, dann mountet man einfach nur das auFS nicht und bootet von der "heilen" Systempartition.
Ah, vielen Dank für die Erklärung! Jetzt habe ich das endlich verstanden, ich hatte mich vorher schon gefragt, wie das funktionieren soll, einen nicht-beschreibbaren Datenträger zu beschreiben ;)

Daher verstehe ich noch nicht, was man damit im NAS will?
So wie ich das verstanden habe (wird auch in vielen OpenMediaVault-Anleitungen so empfohlen), ist die Idee, alle Festplatten mit MergerFS/UnionFS/AUFS zu einem Pool zusammenzufassen, damit man so Probleme wie "Videofestplatte ist voll, dann schiebe ich die neuen Videos mal auf die Fotofestplatte" vermeidet. Mit meinen 2x 4TB würde ich dann also einfach einen 8TB-Pool erstellen, und die Idee wäre dann, dass das Dateisystem die Daten im Hintergrund passend auf die einzelnen Platten verteilt. Spricht da groß etwas dagegen?

Ich habe hier einen Bericht über eine mögliche Ursache für Datenverlust mit MergerFS und SnapRAID gefunden (warum hat der Autor eigentlich mehr Paritäts-Speicherplatz als Daten-Speicherplatz?), aber wäre das nicht etwas, was mit einem Dateiserver mit normalen ext4-Platten oder einem RAID 5 auch passieren könnte?
 
Ich habe noch diesen Guide hier gefunden, um mit FreeNAS ein externes Backup zu realisieren. Geht das also möglicherweise doch?
 
Oh, das klingt natürlich super. Gingen denn folgende Szenarien? Und wie "gefährlich" wäre so ein Umbau für die Daten?
- RAID 5 einrichten mit 2x 4TB sowie 1x 3TB (= 6TB RAID 5), dann später die 3TB durch 1x 4TB ersetzen und somit das RAID auf 8TB erweitern?
- RAID 5 einrichten mit 2x 4TB sowie 2x 3TB (= 9TB RAID 5), dann später die 2x 3TB durch 1x 4TB ersetzen und das RAID auf 8TB verkleinern?
Szenario 1: Kein Problem und sollte auch relativ ungefährlich sein.
Szenario 2: Ist wohl auch möglich, aber nicht ganz so einfach wie die Erweiterung und vor allem nicht so ungefährlich.

Zu RAID 5 aber noch eine Ergänzung: https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/ Das erklärt, warum RAID5 eventuell auch "gefährlich" sein kann. Trotzdem darf man nicht vergessen, dass bei RAID1 oder beim Einzelbetrieb der HDDs das Problem nicht weniger existiert. Los wird man das Problem nur mit Dateisystemen, die Checksummen der Daten bilden (ZFS und btrfs) und/oder RAID6.

Als Dateisystem für die HDDs hätte ich jetzt einfach ext4 gewählt, spricht da etwas dagegen?
ext4 ist solide und gut, außerdem auch bei vielen kleinen Dateien schnell. Unter einem 64bit-System eingerichtet kommt man auch nicht an Größenprobleme (auf 32 bit eingerichtet glaube ich 15 oder 18 TB oder so).

Will man besondere Features nutzen, ist ext4 doof. ext4 kann keine Snapshots, keine Subvolumes, keine Checksums, usw. Aber dafür ist es absolut stabil und einfach zu bedienen (in der Regel muss man gar nichts bedienen). Andere Dateisysteme haben halt dann gleich andere Nachteile. btrfs frisst gerne Daten und ist nicht ganz einfach zu warten, ZFS ist jetzt auch nicht nur intuitiv und kann halt schwerer erweitert werden, usw. Das perfekte Dateisystem gibt es nicht, man muss sich überlegen, was man will bzw. braucht. Ich möchte z.B. aufgrund von SBR (Silent Bit Rod) nicht mehr auf Checksums verzichten. Dann bleiben aber nur noch ZFS und btrfs übrig. Ebenso nutze ich gerne Snapshots für Backups, da bleiben auch nur die beiden übrig. Aber ZFS kann man halt schwerer erweitern, btrfs frisst meine Daten, alles nicht das Wahre.
Ich will ja regelmäßig eine USB-HDD anschließen, um ein Backup des kompletten NAS zu ziehen. Da hatte Adun auf der vorherigen Seite mit seinem FreeNAS-System mit ZFS getestet und konnte keine USB-Datenträger ohne Datenverlust mounten.
Oh, okey... Eigentlich müsste man aber auch externe ZFS-Datenträger vernünftig mounten können. Wundert mich.

So wie ich das verstanden habe (wird auch in vielen OpenMediaVault-Anleitungen so empfohlen), ist die Idee, alle Festplatten mit MergerFS/UnionFS/AUFS zu einem Pool zusammenzufassen, damit man so Probleme wie "Videofestplatte ist voll, dann schiebe ich die neuen Videos mal auf die Fotofestplatte" vermeidet. Mit meinen 2x 4TB würde ich dann also einfach einen 8TB-Pool erstellen, und die Idee wäre dann, dass das Dateisystem die Daten im Hintergrund passend auf die einzelnen Platten verteilt. Spricht da groß etwas dagegen?
Ah, jetzt verstehe ich, was sie da machen. Sie legen ein Overlay-Dateisystem über eine ggf. volle und damit nicht mehr beschreibbare HDD und das Overlay-FS schreibt die Daten in Wirklichkeit auf eine andere HDD. Geschickt. Aber auch etwas "dreckig", wie ich finde. Hinterher weißt du nämlich in Wirklichkeit doch nicht mehr, auf welcher HDD deine Daten liegen. Du glaubst dann, dass deine Fotos auf der Foto-HDD liegen und deine Videos auf der Video-HDD (und backupst vielleicht nur die Foto-HDD, weil dir die Videos nicht so wichtig sind). Aber dann ist die Video-HDD voll, er schreibt Videos auf die Foto-HDD. Irgendwann ist beides voll und du löscht alte Videos, die *wirklich* auf der Video-HDD liegen. Die Foto-HDD ist aber damit immer noch voll und neue Fotos landen plötzlich auf der Video-HDD, die du gar nicht backupst.
So ist zumindest jetzt mein Verständnis von diesem Konzept und dann sehe ich keinen Vorteil mehr darin...

Ich habe hier einen Bericht über eine mögliche Ursache für Datenverlust mit MergerFS und SnapRAID gefunden (warum hat der Autor eigentlich mehr Paritäts-Speicherplatz als Daten-Speicherplatz?), aber wäre das nicht etwas, was mit einem Dateiserver mit normalen ext4-Platten oder einem RAID 5 auch passieren könnte?
Wenn ich die Story richtig verstehe, hat er eine Platte an der Quelle gelöscht und aufs Ziel verschoben. Da SnapRAID (wie oben schon angemerkt) die Parität nicht live berechnet, sondern man erst manuell ein Backup anwerfen muss, gab es in diesem Fall noch keine Parität. Die HDD ist ausgefallen (zumindest an der Stelle, an der die Datei liegt) und damit hat man verloren. Datei ist an der Quelle weg, Backup gibt es (noch) nicht bzw. keine Parität, da der Fehler nach verschieben und vor Backup/Paritätsberechnung passiert ist. Da haben wir ein schönes Beispiel für die Nachteile von SnapRAID gegenüber "echtem" RAID. Daher: Nein, mit einem RAID5 wäre das nicht passiert. Beim Schreiben der Datei wäre auch gleichzeitig die Parität berechnet worden. Wenn dann eine HDD ausfällt wie in diesem Fall, hätte man dank der Parität die Daten wiederherstellen können.
Ich habe noch diesen Guide hier gefunden, um mit FreeNAS ein externes Backup zu realisieren. Geht das also möglicherweise doch?
Klingt so. Ehrlich gesagt würde mich auch wundern, wenn das mit FreeNAS nicht zumindest in irgendeiner Form ginge. Selbst benutzt habe ich FreeNAS noch nicht.
 
Die Statistik von Backblaze kannst Du vergessen: Sie kaufen bevorzugt "billigst" ein, Rückläufer, Recertified usw. und betreiben die Platten oft außerhalb der vom Hersteller vorgeschriebenen Parameter für Einbaulage und Betriebstemperatur...
 
Die Backblaze Statistik sagte IMHO früher nur aus, daß sich günstige Consumer Festplatten (Desktop Modelle, usw) weniger gut für einen HighWorkLoad Einsatz eignen als die teuren RAID, NAS, Enterprise Festplatten Modelle. Die Spezifikation bei Consumer sieht nunmal keinen 24/7 Betrieb vor, entsprechend geht eben die Ausfallrate nach oben. Ob Backblaze da unterm Strich trotzdem Geld damit spart kann ich nicht beurteilen. Wesentlich interessanter fände ich die Statistik jedenfalls, wenn sie tatsächlich nur die Enterpise Modelle einsetzen und "bewerten" würden. Aber so... schade um die Zeit fürs Lesen :)
 
Ich fahre im täglichen Betrieb unter Debian Strech mit dem Gespann aus dm-crypt und lvm ganz gut. Verwaltet werden zwei Toshiba DT01ACA300, beide laufen seid mindestens einem Jahr. An lvm schätze ich, dass auf Level einzelner Logical Volumes entschieden werden kann, welcher RAID-Typ realisiert werden soll. So kann das Video Volume über mehrere Platten gestriped werden und die Backup Volumes werden redundant verteilt. Snapshots für das tägliche Backup oder vor dem OS Upgrade können angelegt werden oder das gesamte Hostsystem im laufenden Betrieb auf neue Platten migriert werden. Gut, Letzteres sollte nicht zu häufig vorkommen, erspart aber einiges an Zeit und Aufwand.

Tägliche Backups von Desktop und Notebook realisiere ich mit dirvish. Einmal in der Woche werden die Backup Volumes auf ein externes Laufwerk gespiegelt. Einmal im Monat wird auf ein zweites Laufwerk gespiegelt, dass dann bei den Eltern oder im Banksafe landet. dirvish erzeugt einiges an Plattenlast, automatische Backups sollten daher nur dann erfolgen, wenn das System gerade nicht genutzt wird.

Mein Anwendungsfall ist ein Desktopsystem, dass für ein kleines Netzwerk noch Aufgaben als zentraler Backupserver und Storage übernimmt. Weboberflächen werden nicht genutzt.
 
Szenario 1: Kein Problem und sollte auch relativ ungefährlich sein.
Szenario 2: Ist wohl auch möglich, aber nicht ganz so einfach wie die Erweiterung und vor allem nicht so ungefährlich.

Zu RAID 5 aber noch eine Ergänzung: https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/ Das erklärt, warum RAID5 eventuell auch "gefährlich" sein kann. Trotzdem darf man nicht vergessen, dass bei RAID1 oder beim Einzelbetrieb der HDDs das Problem nicht weniger existiert. Los wird man das Problem nur mit Dateisystemen, die Checksummen der Daten bilden (ZFS und btrfs) und/oder RAID6.
Okay, ich hab jetzt eine dritte HDD bestellt - nachdem heute erstmal Mist geliefert wurde (nicht gepolstert verschickt, HDD hat dann im Betrieb vibriert wie noch was), muss ich jetzt noch auf Ersatz warten, aber es werden dann von Anfang an drei 4TB.

ext4 ist solide und gut, außerdem auch bei vielen kleinen Dateien schnell. Unter einem 64bit-System eingerichtet kommt man auch nicht an Größenprobleme (auf 32 bit eingerichtet glaube ich 15 oder 18 TB oder so).
Will man besondere Features nutzen, ist ext4 doof. ext4 kann keine Snapshots, keine Subvolumes, keine Checksums, usw. Aber dafür ist es absolut stabil und einfach zu bedienen (in der Regel muss man gar nichts bedienen). Andere Dateisysteme haben halt dann gleich andere Nachteile. btrfs frisst gerne Daten und ist nicht ganz einfach zu warten, ZFS ist jetzt auch nicht nur intuitiv und kann halt schwerer erweitert werden, usw. Das perfekte Dateisystem gibt es nicht, man muss sich überlegen, was man will bzw. braucht. Ich möchte z.B. aufgrund von SBR (Silent Bit Rod) nicht mehr auf Checksums verzichten. Dann bleiben aber nur noch ZFS und btrfs übrig. Ebenso nutze ich gerne Snapshots für Backups, da bleiben auch nur die beiden übrig. Aber ZFS kann man halt schwerer erweitern, btrfs frisst meine Daten, alles nicht das Wahre.
OK, ich glaube, als Linux-Einsteiger wäre mir tatsächlich ext4 am liebsten. Snapshots brauche ich nicht, denke ich - mir geht es hauptsächlich um den Schutz vor einem Hardwareausfall (daher eben RAID) und eine zweite Sicherungskopie (die zusätzliche 8TB-HDD). Wie "gefährlich" ist denn Silent Bit Rot?

Ah, jetzt verstehe ich, was sie da machen. Sie legen ein Overlay-Dateisystem über eine ggf. volle und damit nicht mehr beschreibbare HDD und das Overlay-FS schreibt die Daten in Wirklichkeit auf eine andere HDD. Geschickt. Aber auch etwas "dreckig", wie ich finde. Hinterher weißt du nämlich in Wirklichkeit doch nicht mehr, auf welcher HDD deine Daten liegen. Du glaubst dann, dass deine Fotos auf der Foto-HDD liegen und deine Videos auf der Video-HDD (und backupst vielleicht nur die Foto-HDD, weil dir die Videos nicht so wichtig sind). Aber dann ist die Video-HDD voll, er schreibt Videos auf die Foto-HDD. Irgendwann ist beides voll und du löscht alte Videos, die *wirklich* auf der Video-HDD liegen. Die Foto-HDD ist aber damit immer noch voll und neue Fotos landen plötzlich auf der Video-HDD, die du gar nicht backupst.
So ist zumindest jetzt mein Verständnis von diesem Konzept und dann sehe ich keinen Vorteil mehr darin...
Stimmt, da hast du Recht. Die Idee verwerfe ich dann ja eh dank RAID.

Nein, mit einem RAID5 wäre das nicht passiert. Beim Schreiben der Datei wäre auch gleichzeitig die Parität berechnet worden. Wenn dann eine HDD ausfällt wie in diesem Fall, hätte man dank der Parität die Daten wiederherstellen können.
Okay, gut :) danke für die Erklärung!

Klingt so. Ehrlich gesagt würde mich auch wundern, wenn das mit FreeNAS nicht zumindest in irgendeiner Form ginge. Selbst benutzt habe ich FreeNAS noch nicht.
Da muss ich mich dann auch nochmal einlesen, gibt ja sicher auch Erfahrungsberichte von anderen, die so etwas schonmal versucht haben einzurichten.

Ich fahre im täglichen Betrieb unter Debian Strech mit dem Gespann aus dm-crypt und lvm ganz gut. Verwaltet werden zwei Toshiba DT01ACA300, beide laufen seid mindestens einem Jahr. An lvm schätze ich, dass auf Level einzelner Logical Volumes entschieden werden kann, welcher RAID-Typ realisiert werden soll. So kann das Video Volume über mehrere Platten gestriped werden und die Backup Volumes werden redundant verteilt. Snapshots für das tägliche Backup oder vor dem OS Upgrade können angelegt werden oder das gesamte Hostsystem im laufenden Betrieb auf neue Platten migriert werden.
Ich glaube, das ist für mich dann nicht so wichtig... ich will ja bei allen Daten die Ausfallsicherheit haben, da ich die Videos nicht nochmal woanders gespeichert habe.
Und Snapshots funktionieren mit lvm dann wie bei ZFS?
 
Zuletzt bearbeitet:
OK, ich glaube, als Linux-Einsteiger wäre mir tatsächlich ext4 am liebsten. Snapshots brauche ich nicht, denke ich - mir geht es hauptsächlich um den Schutz vor einem Hardwareausfall (daher eben RAID) und eine zweite Sicherungskopie (die zusätzliche 8TB-HDD).

Snapshots bieten sich vor allem bei Backups an um sicherstellen zu können, dass das Backup keine inkoherenten Daten enthält.

Ich glaube, das ist für mich dann nicht so wichtig... ich will ja bei allen Daten die Ausfallsicherheit haben, da ich die Videos nicht nochmal woanders gespeichert habe.

Ah ok, ich nutze mein Video Volume als Cache für optische Medien oder TV-Aufnahmen, da ist es nicht zu wichtig, wenn das kaputt geht.

Und Snapshots funktionieren mit lvm dann wie bei ZFS?

Keine Ahnung, wie zfs das macht, lvm macht standardmäßig COW. Sobald du im Quellvolume etwas änderst, wird der vorherige Stand in das Snapshotvolume gespeichert. Vielleicht sollte noch erwähnt werden, dass lvm nur die Volumes verwaltet. Welches Dateisystem im Volume landet, bleibt dir überlassen.
 
OK, ich glaube, als Linux-Einsteiger wäre mir tatsächlich ext4 am liebsten. Snapshots brauche ich nicht, denke ich - mir geht es hauptsächlich um den Schutz vor einem Hardwareausfall (daher eben RAID) und eine zweite Sicherungskopie (die zusätzliche 8TB-HDD). Wie "gefährlich" ist denn Silent Bit Rot?
Mal ein bisschen Lektüre:
https://www.it-administrator.de/themen/storage/fachartikel/111409.html
https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
https://www.zdnet.com/article/has-raid5-stopped-working/
Statt "nur ZFS kann das" sollte man aber ergänzen, dass btrfs das auch kann, das noch nicht sehr verbreitete bcachefs auch.


Und Snapshots funktionieren mit lvm dann wie bei ZFS?
AFAIK ja, AFAIK sind sie aber langsam. Außerdem muss man dann wieder gut planen, weil LVM etwas eher mit Partitionen vergleichbares erstellt und dann Platz gelassen werden muss für die Snapshots.

Snapshots bieten sich vor allem bei Backups an um sicherstellen zu können, dass das Backup keine inkoherenten Daten enthält.
Genau das ist ein ganz wichtiger Punkt. Beispiel:
Ich mache ein Backup, dies dauert aufgrund der Datenmenge eine Weile. Auf meinem Laufwerk befinden sich die Ordner A B und C. Das Backup läuft durch, hat A fertig und ist bei B. Aus irgendeinem Grund (ich denke nicht drüber nach und mache es selbst oder irgendeine Software macht es) wird nun eine Datei von C nach A verschoben. Das Backup hat A aber schon fertig und wenn es bei C ankommt, ist die Datei plötzlich weg. In meinem Backup ist diese wichtige Datei plötzlich überhaupt nicht vorhanden, obwohl alle drei Ordner im Backup sind.
Anschaulicheres Beispiel: Ich habe ein Krankenhaus und mache ein Backup. Ein Patient wird während des Backups von einer Station auf eine andere verlegt. Ist die Station, auf die er verlegt wird, schon durchs Backup durch, die Station, von der er kommt, aber noch nicht, haben wir das gleiche Phänomen. In unserem Backup ist der Patient nun überhaupt nicht vorhanden.
Hier können Snapshots helfen. Man erstellt einen Snapshot und friert damit den aktuellen Stand ein. Im Hintergrund können sich natürlich schon Änderungen ergeben, die sind dann aber nicht im Snapshot, der ist ja eingefroren. Jetzt backuppe ich nicht den aktuellen Stand, sondern den Snapshot und habe damit zu einem definierten Stand zum definierten Zeitpunkt ohne Inkonsistenzen.
 
Okay. Die Vorteile von ZFS klingen schon ziemlich gut... wobei ich mich schon frage, ob ich das als "Heimanwender" wirklich brauche. Aber Snapshots klingen schon cool, muss ich sagen.

Ihr würdet also davon abraten, RAID 5 mit so großen HDDs heute noch einzusetzen?

Würdet Ihr ZFS dann nur mit einem FreeBSD-basierten System wie FreeNAS einsetzen, oder könnte ich auch gut OpenMediaVault mit dem ZFS-Plugin nutzen?

Und hat irgendjemand hier Erfahrung damit, Backups von einem ZFS-NAS auf eine USB-HDD zu ziehen? Ich würde nämlich ungern noch einen zweiten Server betreiben müssen, nur um Backups machen zu können.
 
Du kannst natürlich Backups von ZFS auf USB ziehen - es werden ja nahezu beliebige Dateisysteme unterstützt. Ob Freenas (FreeBSD) oder Openmediavault (Debian) ist ganz dir überlassen - beide haben unterschiedliche Ansprüche. Warum setzt du nicht beide mal als VM auf und schaust dir an womit du klar kommst?

Zum Thema Raid 5: Erst ein https://www.heinlein-support.de/upload/slac08/Heinlein-RAID_Mathematik_fuer_Admins.pdf Link - Seite 19. Bitfehlerwahrscheinlichkeit bei Volumen - ab 12TB Gesamtvolumen ist die Bitfehlerwahrscheinlichkeit 100% - dies würde den Rebuild eines Raid5 fehlschlagen lassen und alle Daten sind wech....
 
Ihr würdet also davon abraten, RAID 5 mit so großen HDDs heute noch einzusetzen?
RAID1 oder RAID5 sind immerhin schon besser als gar kein RAID, aber RAID6 wäre schon zu empfehlen, ja.

Würdet Ihr ZFS dann nur mit einem FreeBSD-basierten System wie FreeNAS einsetzen, oder könnte ich auch gut OpenMediaVault mit dem ZFS-Plugin nutzen?
ZFSonLinux läuft inzwischen auch recht gut. Ich denke, das kann man inzwischen auch bedenkenlos einsetzen - wobei ich trotzdem ein BSD-basiertes System empfehlen würde, wenn man die freie Wahl hat.

Zum Thema Raid 5: Erst ein https://www.heinlein-support.de/upload/slac08/Heinlein-RAID_Mathematik_fuer_Admins.pdf Link - Seite 19. Bitfehlerwahrscheinlichkeit bei Volumen - ab 12TB Gesamtvolumen ist die Bitfehlerwahrscheinlichkeit 100% - dies würde den Rebuild eines Raid5 fehlschlagen lassen und alle Daten sind wech....
Naja, ganz so schlimm sieht es für RAID5 nicht aus. Denn:
- hält man seine Dateien immer mit zwei Kopien vor (z.B. RAID 1), sieht es dort genau so schlecht/gut aus. Das macht es nicht besser, aber man darf nicht vergessen, dass RAID 5 nicht allein so "böse" ist.
- oft sind das auch "stille" Lesefehler. Gut: Das RAID bekommt davon gar nix mit. Schlecht: Die eine Datei, die an der Stelle gerade gelesen wurde, ist natürlich trotzdem dann beschädigt. Aber deswegen sind nicht gleich alle Daten weg.
- selbst wenn es kein "stiller" Fehler ist, sondern tatsächlich der Rebuild hart scheitert: Mit "--force"-Optionen bringt man sein RAID trotzdem dazu, seine Daten preiszugeben. Dann sind auch dann nicht alle Daten weg, sondern eben - wie beim Punkt hier drüber - ist nur die eine Datei ggf. beschädigt.

Wenn man sich den Ärger im Fall der Fälle sparen will, dann hilft natürlich nur RAID 6.
 
Du kannst natürlich Backups von ZFS auf USB ziehen - es werden ja nahezu beliebige Dateisysteme unterstützt. Ob Freenas (FreeBSD) oder Openmediavault (Debian) ist ganz dir überlassen - beide haben unterschiedliche Ansprüche. Warum setzt du nicht beide mal als VM auf und schaust dir an womit du klar kommst?
Das hab ich schonmal gemacht, mir gefällt OpenMediaVault insgesamt deutlich besser, auch aufgrund der verfügbaren Plugins. Ich dachte nur, dass ZFS halt in FreeNAS so tief verankert ist und in OMV nur eine "Pluginlösung" darstellt, sodass ich mich frage, ob das sicher genug ist, ZFS in OMV zu benutzen.

RAID1 oder RAID5 sind immerhin schon besser als gar kein RAID, aber RAID6 wäre schon zu empfehlen, ja.
Okay! Ich könnte ja auch mit einem RAID5 anfangen und dann nachher auf ein RAID6 erweitern, wenn ich das richtig verstanden habe, oder? Nur bei ZFS ginge das nicht, also von RAIDZ1 auf RAIDZ2?

Ich nehme mal an, du würdest aber trotzdem noch eher ZFS mit RAIDZ1 empfehlen als ein RAID5, das später auf ein RAID6 erweitert wird?

ZFSonLinux läuft inzwischen auch recht gut. Ich denke, das kann man inzwischen auch bedenkenlos einsetzen - wobei ich trotzdem ein BSD-basiertes System empfehlen würde, wenn man die freie Wahl hat.
Okay, dann würde ich es, glaube ich, wirklich mit OMV umsetzen.

- hält man seine Dateien immer mit zwei Kopien vor (z.B. RAID 1), sieht es dort genau so schlecht/gut aus. Das macht es nicht besser, aber man darf nicht vergessen, dass RAID 5 nicht allein so "böse" ist.
- oft sind das auch "stille" Lesefehler. Gut: Das RAID bekommt davon gar nix mit. Schlecht: Die eine Datei, die an der Stelle gerade gelesen wurde, ist natürlich trotzdem dann beschädigt. Aber deswegen sind nicht gleich alle Daten weg.
- selbst wenn es kein "stiller" Fehler ist, sondern tatsächlich der Rebuild hart scheitert: Mit "--force"-Optionen bringt man sein RAID trotzdem dazu, seine Daten preiszugeben. Dann sind auch dann nicht alle Daten weg, sondern eben - wie beim Punkt hier drüber - ist nur die eine Datei ggf. beschädigt.
Oh, das ist schonmal sehr gut zu wissen, dass man ein RAID doch auch noch wiederherstellen kann, wenn der Rebuild scheitert.
 
Zuletzt bearbeitet:
  • ok1.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen
Zurück
Oben