Heimische Dokumenten und Backup Speicherlösung?
-
Xin schrieb:
Die Synchronisation läuft eigentlich ohne großes Gerödel ab, Sequenzielles lesen. Ich sehe hier bestenfalls eine (thermische) Belastung der Platine, mechanisch erscheint mir die Sache relativ uninteressant.
Das Problem ist auch eher, dass alle Sektoren gelesen werden müssen, was normalerweise nicht passiert. Wenn dabei auch nur ein einziger der vielen Milliarden Sektoren nicht mehr lesbar sein sollte, ist das RAID hinüber.
Xin schrieb:
Christoph schrieb:
nman schrieb:
RAID6 ist auch nichts anderes als RAID5, also auch Block-Level Striping, aber gleich mit doppelter Parität
Ich möchte hier noch hinzufügen, dass man ein Soft-RAID unter Linux im laufenden Betrieb von RAID5 auf ein RAID6 erweitern kann, indem man eine weitere Platte einbaut. Man kann also ein altes RAID5 in ein RAID6 umwandeln, ohne alles neu machen zu müssen.
Ich meine auch, dass man eine zusätzliche Parity-Platte jederzeit an das RAID5 anhängen kann. Ob das dann allerdings RAID6 heißt, weiß ich nicht.
Da muss ich mich mal schlau lesen, gucken, was ich damals für Platten gekauft habe und nochmal was an Reserve ranschaffen... und halt mehr SATA-Steckplätze... gibt's keine SATA-PCI-Card mit 12 Ports oder so?
Das ist eventuell das, was nman meinte mit "RAID5 + spare". Die Spare-Platte ist im Normalbetrieb inaktiv und wird erst aktiviert, sobald eine Platte im RAID5 ausfällt. Sowas halte ich nicht für besonders sinnvoll, da würde ich gleich RAID6 nehmen.
Wovon ich rede, ist reshaping. Man kann unter Linux ein RAID5 im laufenden Betrieb in ein echtes RAID6 umwandeln.
-
Ob man Git mag oder nicht, die Repos sind wirklich verflucht robust. Kaputte SVN-Repos sind mir schon oft begegnet, kaputte Git-Repos noch nie. Ganz unabhaengig davon ist jedes moderne verteilte VCS in Sachen Datensicherheit klassischen zentralisierten VCS ueberlegen; wenn ein einzelnes Repo weg ist, tut das nicht weh, weil ja ohnehin jedes Working Directory die vollstaendige Versionsgeschichte beinhaltet.
Christoph schrieb:
Das ist eventuell das, was nman meinte mit "RAID5 + spare". Die Spare-Platte ist im Normalbetrieb inaktiv und wird erst aktiviert, sobald eine Platte im RAID5 ausfällt. Sowas halte ich nicht für besonders sinnvoll, da würde ich gleich RAID6 nehmen.
Ich auch nicht, RAID6 ist natuerlich sinnvoller. Trotzdem ist "RAID5 + hot spare" sehr verbreitet, daher auch mein Hinweis besser RAID6 zu verwenden.
-
nman schrieb:
Christoph schrieb:
Das ist eventuell das, was nman meinte mit "RAID5 + spare". Die Spare-Platte ist im Normalbetrieb inaktiv und wird erst aktiviert, sobald eine Platte im RAID5 ausfällt. Sowas halte ich nicht für besonders sinnvoll, da würde ich gleich RAID6 nehmen.
Ich auch nicht, RAID6 ist natuerlich sinnvoller.
Ich meinte den Teil hier:
nman schrieb:
Natürlich kannst du ein Hotspare dazukaufen, aber wenn du schon ein RAID5 mit Hotspare hast, kannst du das auch einfach gleich ein RAID6 verwenden, das wesentlich zuverlässiger ist.
Ich hatte in meinem Posting nur ausgelassen, dass du davon auch abgeraten hast.
-
Wenn wir schon über die Unsicherheit von RAID5 etc. reden...
Gibt es eigentlich schon DAU-freundliche, leistbare Home-NAS Teile mit ZFS/RAID-Z?
Also so schön mit klickibunti und allem?Weil... RAID6 ist halt auch nicht das wahre, vor allem wenn der RAID Controller kein Scrubbing macht (soweit ich weiss machen das die HomeNASen alle nicht?).
-
Christoph: Klar, ich wollte nur klarstellen, was ich meinte. War mir nicht sicher, ob das fuer den Rest der Welt auch verstaendlich war.
hustbaer schrieb:
Wenn wir schon über die Unsicherheit von RAID5 etc. reden...
Gibt es eigentlich schon DAU-freundliche, leistbare Home-NAS Teile mit ZFS/RAID-Z?
Also so schön mit klickibunti und allem?Es gibt ein paar fix-fertige FreeNAS-Appliances, aber die sind fuer meinen Geschmack etwas teuer fuer zuhause.
Weil... RAID6 ist halt auch nicht das wahre, vor allem wenn der RAID Controller kein Scrubbing macht (soweit ich weiss machen das die HomeNASen alle nicht?).
Ich haette auch lieber RAID-Z2, aber unter GNU/Linux ist RAID6 wohl trotzdem die beste Wahl.
Software-RAID kann man recht bequem scrubben lassen, das laesst sich auch gut in einen Cronjob verpacken sofern es die verwendete Distro nicht ohnehin schon macht.
-
hustbaer schrieb:
Weil... RAID6 ist halt auch nicht das wahre, vor allem wenn der RAID Controller kein Scrubbing macht (soweit ich weiss machen das die HomeNASen alle nicht?).
Linux macht das. Je nach Distribution muss man es noch manuell aktivieren.
RAID6-Scrubbing bei mdraid sieht so aus, dass alle Sektoren auf allen Platten gelesen und die Parität geprüft wird. Wenn es irgendwo eine Inkonsistenz gibt, wird entweder nichts gemacht und nur der Admin benachrichtigt, oder die betroffenen Paritätsbereiche werden blind neu geschrieben.
Was Linux nicht macht, ist ein Mehrheits-Votum, wenn irgendwas bei einem RAID6 inkonsistent ist. In diesem Fall schreibt Linux pauschal die Paritätsbereiche neu und nimmt einfach an, dass die Datenplatten Recht haben. Die Argumente, warum "smart recovery" unter Linux nicht implementiert ist, hat der mdraid-Autor in seinem Blog ausführlich beschrieben: http://neil.brown.name/blog/20100211050355
ZFS macht smart recovery.
-
Christoph schrieb:
Die Argumente, warum "smart recovery" unter Linux nicht implementiert ist, hat der mdraid-Autor in seinem Blog ausführlich beschrieben: http://neil.brown.name/blog/20100211050355
ZFS macht smart recovery.Danke für den Link (und auch die anderen Informationen)!
Aber Scrubbing ohne Smart-Recovery wäre (für mich) ziemlich sinnlos. Schliesslich will ich mich nicht um die Kiste kümmern, die soll das hübsch selbst machen!
Ja, ZFS macht Recovery. Und weil ZFS auch Prüfsummen hat kann es sogar mit single-parity smart recovern!
Und weil ZFS überhaupt schlauer ist, z.B. die Prüfsumme auch immer beim Lesen prüft, und nicht nur beim Scrubben, kann es auch ohne Probleme smart recovern.nman schrieb:
Es gibt ein paar fix-fertige FreeNAS-Appliances, aber die sind fuer meinen Geschmack etwas teuer fuer zuhause.
Hast du vielleicht nen Link mit einer Liste/Übersicht/...? Ich hab relativ lange gesucht, und irgendwie nix gefunden...
Zumindest nix was preislich mit einem DroboFS mithalten könnte.Software-RAID kann man recht bequem scrubben lassen, das laesst sich auch gut in einen Cronjob verpacken sofern es die verwendete Distro nicht ohnehin schon macht.
OK. Aber ohne recovery finde ich das Scrubben jetzt nicht so toll.
-
@alle
Hat jemand von euch zufällig genauere Infos zum DroboFS (BeyondRAID)?
In den offiziellen PDFs/der Drobo-Homepage finde ich immer nur den Hinweis dass das Ding scrubben tut. Aber nicht wie genau es das macht. Und nicht genau was es dann wirklich machen kann wenn ein Fehler gefunden wurde.Also z.B. ob es Prüfsummen verwendet, oder einfach auf gut Glück repariert, oder ...?
-
hustbaer schrieb:
Aber Scrubbing ohne Smart-Recovery wäre (für mich) ziemlich sinnlos. Schliesslich will ich mich nicht um die Kiste kümmern, die soll das hübsch selbst machen!
Scrubbing unter Linux macht Recovery vollautomatisch. Es macht nur nicht das, was der mdraid-Autor "smart recovery" nennt. Normalerweise ist das aber kein Nachteil, wenn man dem mdraid-Autor glaubt. Recovery funktioniert unter Linux auf jeden Fall automatisch ohne manuellen Eingriff.
-
Ich hab den Beitrag kurz überflogen...
Einige der Argumente kann ich nicht ganz nachvollziehen - z.B. ein Device das 1x Mist geschrieben hat muss nicht bei jedem weiteren Schreibzugriff (auf die selbe logische Sektornummer) wieder Mist schreiben. Festplatten machen ja schliesslich selbst Bad-Sector-Remapping, und vermutlich wird es auch "temporäre" Probleme geben die beim Schreiben auftreten können -- auf Grund von Spannungsschwankungen oder was auch immer.
Und dann vergleicht er auch nur die Optionen die es seiner Meinung nach mit der aktuellen md/raid Implementierung gibt.
Darauf dass man Konsistenz-Checks bei jedem Lesezugriff machen kann, bevor man die Daten rausgibt (wie es ZFS macht) geht er z.B. überhaupt nicht ein. Und leitet aus der impliziten Annahme dass die Daten ungeprüft rausgehen das Problem ab, dass ja Anwendungen bereits die fehlerhaften Daten erhalten und weiterverarbeitet haben könnten. Und eine nachträgliche Korrektur daher bloss zu noch mehr Problemen führen würde.
Was grundsätzlich richtig ist. Die Schlussfolgerung "Daten reparieren ist böse" ist aber nur eine mögliche, man kann genau so gut sagen "Daten ungecheckt rausgeben ist böse".Dass unter Konsistenzchecks bei jedem Lesezugriff die Performance leidet sollte klar sein. Aber es gibt halt verschiedene Anforderungen und daher auch verschiedene Lösungsansätze. ZFS ist was das angeht definitiv nicht auf maximale Performance getrimmt, sondern eher auf maximale Datensicherheit.
(Dass ZFS mittlerweile Triple-Parity unterstützt ist wohl ein deutlicher Hinweis darauf was für Schwerpunkte ZFS hat.)--------
Für md/raid wird das was er schreibt wohl stimmen -- zumindest wenn man md/raid nicht komplett neu erfinden will. Daraus abzuleiten dass es bei allen Systemen so wäre, bzw. dass das Scrubbing von md/raid keine Nachteile gegenüber anderen Systemen hätte, ist aber ein Fehler.
Es ist definitiv ein Nachteil gegenüber Smart-Recovery mit Prüfsummen ala ZFS. Smart-Recovery mit Prüfsummen erhöht die Chance dass die Daten danach OK sind drastisch gegenüber dem was md/raid macht.
Und ich privat tendiere da eher zu Datensicherheit. Ob ich jetzt mit den max. 100 MB/s die über mein Gigabit drübergehen lesen/schreiben kann, oder nur mit 25~30 MB/s (= das was ich derzeit so von meinem Storage Space/ReFS System bekomme) ist mir dabei relativ egal.
-
hustbaer schrieb:
Einige der Argumente kann ich nicht ganz nachvollziehen - z.B. ein Device das 1x Mist geschrieben hat muss nicht bei jedem weiteren Schreibzugriff (auf die selbe logische Sektornummer) wieder Mist schreiben. Festplatten machen ja schliesslich selbst Bad-Sector-Remapping, und vermutlich wird es auch "temporäre" Probleme geben die beim Schreiben auftreten können -- auf Grund von Spannungsschwankungen oder was auch immer.
Ja, das schreibt er auch. mdraid behandelt diesen Fall auch schon explizit: Wenn ein Lesefehler auftritt, ist das erste, was mdraid versucht, den kaputten Sektor mit Hilfe der Paritätsdaten zu reparieren und dann neuzuschreiben. Erst, wenn das Neuschreiben nicht funktioniert, wird die Platte als fehlerhaft markiert. Ein reiner Lesefehler führt nicht dazu, dass eine Platte aus dem RAID geworfen wird. Insofern sind temporäre Fehler mit mdraid kein Problem.
Nichtsdestotrotz würde ich eine Festplatte austauschen, wenn relocated_sectors steigt.
Zu Checksummen schreibt Neil Brown übrigens das hier: http://neil.brown.name/blog/20110227114201
Kurzfassung: Checksummen gehören nicht in den mdraid-Layer, denn Festplatten und SATA-Interfaces etc. machen intern bereits Checksummen und liefern daher keine falschen Daten. Wenn trotzdem irgendwas schiefgeht, dann helfen nur end-to-end-Checksummen. End-to-end heißt aber User-Ebene, das heißt oberhalb des Dateisystems.Aber ich stimme dir zu, dass ZFS nochmal eine ganze Ecke penibler ist, was Datensicherheit angeht. Leider gibt es für Linux zur Zeit nichts vergleichbares. ZFS unter Linux ist sehr veraltet und lizenztechnisch inkompatibel mit dem Kernel.
Mit btrfs wird hoffentlich irgendwann alles besser. Noch ist es nur nicht so weit, dass ich es einsetzen würde.
Das grundsätzliche Problem ist eben, dass RAID und Dateisystem auf völlig separaten Layern laufen unter Linux. Deswegen kann auch ein Dateisystem, dass Checksummen macht, dem RAID nicht helfen beim Korrigieren von Lesefehlern. ZFS und btrfs machen RAID und Dateisystem beides selbst. Mit der Methode hat das Dateisystem natürlich ganz andere und viel sicherere Möglichkeiten, was die Verwaltung des RAIDs angeht.
Andererseits erhöht sich dadurch aber auch die Komplexität des Dateisystems enorm, damit auch die Wahrscheinlichkeit von Bugs. Ich kann deswegen verstehen, warum es das unter Linux bisher nicht gibt und warum so wenige Dateisysteme das können. Der Aufwand ist einfach gewaltig, und mit separatem RAID-Layer und Dateisystem-Layer ist man mit viel weniger Aufwand am Ziel und hat vermutlich weniger Bugs im RAID-Layer als wenn man den manuell nachimplementiert.
edit: Ein Problem mit "RAID im Dateisystem" ist übrigens Verschlüsselung. Man hat hier effektiv zwei Möglichkeiten: Entweder man verschlüsselt jede einzelne Platte, die im RAID sein soll, separat, was ziemlich umständlich sein kann, weil man dann fürs mounten zuerst jede Platte separat entschlüsseln muss und außerdem neue Platten nicht so einfach ins System einbinden kann.
Oder man baut Verschlüsselung auf Dateisystemebene ein. Das ist das, was ZFS macht. Aber das erhöht den Implementierungsaufwand des Dateisystems noch einmal gewaltig. Gleichzeitig ist eine Verschlüsselung auf Dateisystemebene auch schwieriger umzusetzen als eine komplette Festplattenverschlüsselung, denk ich, einfach weil die Anforderungen viel komplizierter sind als ein simples "verschlüssle das Blockdevice von vorne bis hinten". Das heißt auch wieder, dass die Fehlerwahrscheinlichkeit steigt.
Beide Möglichkeiten haben ihre Nachteile.
Deswegen gefällt mir zur Zeit die simple Linux-Lösung: RAID, Verschlüsselung, Dateisystem sind sauber getrennte Layer, die nichts voneinander wissen müssen. Dadurch verliere ich zwar das eine oder andere schöne Feature wie smart recovery, aber ich denke, dass ich alleine durch die Einfachheit dieser Lösung auch wieder Sicherheit gewinne.
-
hustbaer schrieb:
Hast du vielleicht nen Link mit einer Liste/Übersicht/...? Ich hab relativ lange gesucht, und irgendwie nix gefunden...
Ich habe mich schon lange nicht mehr umgesehen. Habe fuer eine Firma mal sowas gekauft, aber wirklich billig war das damals auch nicht. Zumindest nicht fuer den Privateinsatz.
Zumindest nix was preislich mit einem DroboFS mithalten könnte.
Ueber Drobo habe ich schon eine Menge Gruselgeschichten gehoert und mir ist auch ein wenig unheimlich wie wenige technische Details die zu ihren Produkten verraten. Ich persoenlich waere zu paranoid fuer sowas.
-
Christoph schrieb:
Zu Checksummen schreibt Neil Brown übrigens das hier: http://neil.brown.name/blog/20110227114201
Kurzfassung: Checksummen gehören nicht in den mdraid-Layer, denn Festplatten und SATA-Interfaces etc. machen intern bereits Checksummen und liefern daher keine falschen Daten. Wenn trotzdem irgendwas schiefgeht, dann helfen nur end-to-end-Checksummen. End-to-end heißt aber User-Ebene, das heißt oberhalb des Dateisystems.Tjoah
Das hab' ich mir auch immer gedacht. Andrerseits weiss ich auch dass Hardware, vor allem Consumer-Hardware, oft Scheisse ist.
Und in einem Vortrag zum Thema ZFS at der sprechende Entwickler erwähnt dass sie Daten von einer grossen Firma haben, aus denen hervorgeht dass ca. alle 20 TB (ich hoffe ich hab' mir die Zahl richtig gemerkt) ein "stiller" Einzelbitfehler auftritt.
Heisst: irgendwer baut doch irgendwo Mist. Seis nun die Platte, dar SATA-Controller, der Cache oder das RAM des Servers.Was End-To-End Prüfsummen angeht: ja, stimmt, aber man kann dummerweise nicht alle Netzwerkprotokolle/Applikationsprotokolle/Fileformate übern Haufen werfen.
[EDIT]
Wenn man den Artikel von Neil Brown auf den Punkt bringt steht da drinnen: "das solle man andere (höher gelegene) Schichten machen". Machen sie aber oft genug nicht, und genau das ist das Problem. Wobei es vermutlich besser wäre die zusätzlichen Prüfsummen erst vom Client-PC checken zu lassen, weil man damit den Wirkungsbereich um einige wichtige Komponenten vergrössert. D.h. man müsste es dem Netzwerk-Filesystem beibringen (SMB, NFS, was auch immer) damit möglichst viele Applikationen etwas davon haben.[/EDIT]Wenn man trotzdem (sehr) gute Datensicherheit haben möchte, muss man sich also 'was anderes einfallen lassen, und eben gucken wo man am meisten rausholen kann.
Sogesehen finde ich das was ZFS macht eigentlich ziemlich gut.
Das grundsätzliche Problem ist eben, dass RAID und Dateisystem auf völlig separaten Layern laufen unter Linux. Deswegen kann auch ein Dateisystem, dass Checksummen macht, dem RAID nicht helfen beim Korrigieren von Lesefehlern.
Jo, ist mir schon klar
Andererseits erhöht sich dadurch aber auch die Komplexität des Dateisystems enorm
Weiss nicht. Tut es das?
edit: Ein Problem mit "RAID im Dateisystem" ist übrigens Verschlüsselung. Man hat hier effektiv zwei Möglichkeiten: Entweder man verschlüsselt jede einzelne Platte, die im RAID sein soll, separat, was ziemlich umständlich sein kann, weil man dann fürs mounten zuerst jede Platte separat entschlüsseln muss und außerdem neue Platten nicht so einfach ins System einbinden kann.
Verstehe ich jetzt nicht ganz. Bei "RAID im Dateisystem" hast du statt dem RAID-Layer einen Pool-Layer. Und die Verschlüsselung kannst du genau so gut in den Pool-Layer einbauen. Bzw. als eigenen Layer zwischen Pool und Dateisystem stecken.
Dass die Block-Adresse die der Pool-Layer braucht um einen Block zu finden aus zwei Teilen besteht (Disk-ID und Adresse innerhald der Disk) sollte dabei doch egal sein?Oder man baut Verschlüsselung auf Dateisystemebene ein. Das ist das, was ZFS macht. Aber das erhöht den Implementierungsaufwand des Dateisystems noch einmal gewaltig. Gleichzeitig ist eine Verschlüsselung auf Dateisystemebene auch schwieriger umzusetzen als eine komplette Festplattenverschlüsselung, denk ich, einfach weil die Anforderungen viel komplizierter sind als ein simples "verschlüssle das Blockdevice von vorne bis hinten". Das heißt auch wieder, dass die Fehlerwahrscheinlichkeit steigt.
Jo. Ich denke aber dass es bei ZFS im Dateisystem behandelt wird, einfach weil das flexibler ist, und die Möglichkeit bietet Teile eines Dateisystems bei einem Software-Update neu zu verschlüsseln (weil das alte Verfahren zu langsam oder zu unsicher ist oder was weiss ich), ohne dass man gleich das ganze Volume komplett umschreiben muss.
Deswegen gefällt mir zur Zeit die simple Linux-Lösung: RAID, Verschlüsselung, Dateisystem sind sauber getrennte Layer, die nichts voneinander wissen müssen. Dadurch verliere ich zwar das eine oder andere schöne Feature wie smart recovery, aber ich denke, dass ich alleine durch die Einfachheit dieser Lösung auch wieder Sicherheit gewinne.
Mag sein.
Andrerseits ist ZFS schom mächtig stabil. Die Datenmengen die diverse Firmen auf ZFS gespeichert haben sind unvorstellbar...
Dummerweise gibt es die aktuellste Version halt immer nur für Oracle Solaris.
-
Hab jetzt alle anschaffungen erledigt und auch schon einiges rum gespielt.
Auch wenn ich in diesen Thread auch nur ein viertel verstand, war viel interessantes dabei.Ich habe nun ein Synology DiscStation 212 mit 2x 1TB WD Red platten.
Das NAS verwendet die Internetfreigabe meines Desktop PCs.
MySQL läuft schon und kann Datenbanken erstellen, lesen usw, auch Daten sind schon über Netzwerkfreigaben kopiert.Ich habe nun neue Fragen die aber nichts mehr hiermit zu tun haben, mache ein neuen Thread auf
-
hustbaer schrieb:
edit: Ein Problem mit "RAID im Dateisystem" ist übrigens Verschlüsselung. Man hat hier effektiv zwei Möglichkeiten: Entweder man verschlüsselt jede einzelne Platte, die im RAID sein soll, separat, was ziemlich umständlich sein kann, weil man dann fürs mounten zuerst jede Platte separat entschlüsseln muss und außerdem neue Platten nicht so einfach ins System einbinden kann.
Verstehe ich jetzt nicht ganz. Bei "RAID im Dateisystem" hast du statt dem RAID-Layer einen Pool-Layer. Und die Verschlüsselung kannst du genau so gut in den Pool-Layer einbauen. Bzw. als eigenen Layer zwischen Pool und Dateisystem stecken.
Es dupliziert gut getesteten existierenden Code (dmcrypt). Sowas ist immer eine sehr fragwürdige Aktion.
