Heimische Dokumenten und Backup Speicherlösung?
-
Xin schrieb:
Aktuell stellt sich die Frage für mich kaum. Der Nachteil von solchen RAID Lösungen ist ja auch, dass man nicht mal eben die Daten umkopieren kann. […]
Für das nächste RAID werde ich mich da aber nochmal in Richtung RAID 6 schlau machen. Hast Du da informative Links?
Klar. Ich meinte auch nur David W möge jetzt nicht ein RAID5 anlegen.
RAID6 ist auch nichts anderes als RAID5, also auch Block-Level Striping, aber gleich mit doppelter Parität:
http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_6Also auch keine tollen Restore-Zeiten, aber der zu erwartende Restore tut nicht so furchtbar weh und ist auch sicherer.
Ich hab vor drei Jahren noch 300 Euro für vier bezahlt und dachte der Tsunami wäre nun langsam erledigt.
Nein, die Diskpreise sind immer noch eher übel. Wird erst mit den neueren Chargen weniger, aber weil mittlerweile wohl auch weniger abgesetzt werden, stabilisiert sich das auch nicht so schnell.
Smart-Warnings sind meistens einfach Temperatur-Warnings etc. Festplatten mit Fehlern benutze ich z.B. für Videoaufzeichnungen, Fernsehsendungen aus der Mediathek oder ähnliches.
Klar gibt's auch uninteressante SMART-Warnings, aber ich meinte schon die wichtigeren wie Relocated Sectors, Pending Sectors, … Die anderen teilet mir der smartd ja gar nicht mit.
Das dürfte für private Daten reichen.
Sehe ich auch so. Hauptsache man hat irgendwo ein zuverlässiges Offsite-Backup für die wichtigen Daten. Die Filmsammlung ist dabei typischerweise nicht so kritisch, aber die Firmenrechnungen, Emails oä. sind doch zu wichtig um nur eine Sicherung zu haben, die noch dazu in der selben Wohnung wie die Originale liegt.
-
Ich denke es wird ein Synology. Bei Amazon liest man durchweg gute Bewertungen, besonders bei der Qualität und Lautstärke.
Bei Plattenspeicher reicht derzeit 1TB, ich dachte an nem NAS mit RAID1 und 2x 1TB Platten.
Aufrüsten auf 2 oder mehr TB kann man dann ja, so verstand ich das bisher, immer noch später.
Also 2x ungefähr solche: http://www.amazon.de/Western-Digital-WD10EARX-interne-Festplatte/dp/B0053YKMGA/ref=sr_1_fkmr0_1?s=computers&ie=UTF8&qid=1349428834&sr=1-1-fkmr0Was die Lautstärke an geht würde ich sagen, lass ich die Platten dann in den Ruhezustand gehen und mach mir da keine weitere Gedanken (halt drauf achten sobald eine Platte anfängt Probleme zu machen diese zu wechseln)
Andere fragen ^^:
* Wenn das NAS ein Web interface bereit stellt, komm ich da über Putty rauf oder wie starte ich dann den Terminal? (Eventuell muss da noch was aktiviert werden oder so)
* Wen das NAS offline betrieben wird, also kein W-Lan, was ist eine gute Quelle für Pakete? (Zum runter laden auf den Desktop)(Die Allerwichtigsten Daten habe ich auf eine SD auch noch gesichert, diese SD ist auch nicht im Haus sondern bei meiner Mutter.)
-
David W schrieb:
Also 2x ungefähr solche: http://www.amazon.de/Western-Digital-WD10EARX-interne-Festplatte/dp/B0053YKMGA/ref=sr_1_fkmr0_1?s=computers&ie=UTF8&qid=1349428834&sr=1-1-fkmr0
Sieht gut aus.
Wenn das NAS ein Web interface bereit stellt, komm ich da über Putty rauf oder wie starte ich dann den Terminal? (Eventuell muss da noch was aktiviert werden oder so)
Das Webinterface verwendest du via Browser und für den SSH-Zugriff kannst du einfach Putty verwenden, ja.
Wen das NAS offline betrieben wird, also kein W-Lan, was ist eine gute Quelle für Pakete? (Zum runter laden auf den Desktop)
Gibt ein paar Quellen, aber nachdem das Ding ja eh irgendwie im Netz hängen wird, würde ich eher einen anderen Rechner kurz Router spielen lassen oä. Dann kannst du einfach ipkg installieren und via
ipkg update && ipkg install gitgit installieren.Details findest du im deutschen Synology-Wiki.
-
Xin schrieb:
Für Fotos/Familienvideos würde ich über ein RAID5 nachdenken (4 oder mehr Festplatten) und nichts unterhalb von 2TB verbauen.
Würde ich nicht machen. Ein RAID5 mit Festplatten von 2TB oder mehr ist eine sehr riskante Angelegenheit. Denn wenn eine Platte ausfällt, müssen zum Wiederherstellen der ausgefallenen Platte alle n-1 anderen Platten komplett gelesen werden, was für die Platten eine enorme außergewöhnliche Belastung darstellt. Die Chance, dass genau dadurch eine weitere Platte ausfällt, wär mir zu hoch.
Xin schrieb:
Wichtige Daten solltest Du verschlüsselt(!) auf einen Netzwerkdienst legen - der muss nicht als "Cloud" vermarktet werden... Ich habe dafür einen VServer, den ich als Backup-Müllhalde von anderen Servern verwende - also auch von zu Hause.
Wenn man etwas nimmt, das als "Cloud" vermarktet wird, bekommt man halt deutlich mehr Speicher fürs selbe Geld als wenn man einen VServer nimmt. Ein VServer lohnt sich deswegen nur, wenn man den sowieso für andere Zwecke braucht, würde ich sagen.
Xin schrieb:
Kleine Boot-Platte dazu, irgendwas noch so über ist, um das Betriebsystem zu installieren, Debian drauf, fertig.
Ich hab gute Erfahrung damit gemacht, einen USB-Stick als System-Platte zu nehmen. Ist lautlos, kostet weniger Strom und die Geschwindigkeit der Systemplatte ist bei einem NAS sowieso egal. 1:1-Backups der Systemplatte gestalten sich so auch viel einfacher. Da es nur um ein privates NAS geht, halte ich die mögliche Downtime durch einen kaputten USB-Stick auch für vertretbar.
Xin schrieb:
Platte austauschen, neue Platte als RAID-Laufwerk partitionieren und dem defekten RAID zufügen, Synchronisieren lassen.
Partitionieren würde ich weglassen. Es spricht soweit ich weiß nichts dagegen, die Platte direkt ohne Partitionstabelle ins RAID einzubinden. Im Gegenteil, eine nicht vorhandene Partitionstabelle ist eine Fehlerquelle weniger, und Fehlerquellen minimieren ist bei sowas meine oberste Priorität.
Xin schrieb:
Bei dem 4x2TB-RAID5 dauerte die Synchronisation etwa einen Tag. Seitdem denke ich über ein RAID5 mit zwei Reserve-Platten nach... geht in der Zeit eine der übrigen drei Platten kaputt, sind alle Daten weg.
RAID5 mit zwei redundanten Platten ist ein RAID6.
Xin schrieb:
David W schrieb:
* Bietet ein NAS die Möglichkeit ein eigenen Server zu halten? (z.B.: ein Git Server wo ich Private Daten einchecken könnte) [Kein Requirement]
Manche, die QNAPs bieten eben Subversion, dem ich zur Zeit noch eher vertraue als Git.
Ist unberechtigt, denk ich. Ich hab schon häufiger von kaputten SVN-Repositories gelesen als von kaputten git-Repositories. Um genau zu sein, von kaputten SVN-Repositories hab ich schon gelesen, von kaputten git-Repositories noch nie.
Xin schrieb:
Ein selbst konfigurierter Server kann alles, was Du willst, ist billiger und Du musst selbst sehen, dass er läuft.
Und genau der letzte Punkt wird für den OP das KO-Kriterium sein, vermute ich.
edit: OK, ich kann aus den Postings nicht so gut herauslesen, in wie weit der OP Linux-Kenntnisse hat. Ohne Linux-Kenntnisse wird es sehr zeitaufwendig, ein NAS selber aufzusetzen. Vielleicht geht das auch mit Windows ganz gut, aber das weiß ich nicht.
-
nman schrieb:
Xin schrieb:
Für das nächste RAID werde ich mich da aber nochmal in Richtung RAID 6 schlau machen. Hast Du da informative Links?
Klar. Ich meinte auch nur David W möge jetzt nicht ein RAID5 anlegen.
RAID6 ist auch nichts anderes als RAID5, also auch Block-Level Striping, aber gleich mit doppelter ParitätIch 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.
-
Christoph schrieb:
Xin schrieb:
Für Fotos/Familienvideos würde ich über ein RAID5 nachdenken (4 oder mehr Festplatten) und nichts unterhalb von 2TB verbauen.
Würde ich nicht machen. Ein RAID5 mit Festplatten von 2TB oder mehr ist eine sehr riskante Angelegenheit. Denn wenn eine Platte ausfällt, müssen zum Wiederherstellen der ausgefallenen Platte alle n-1 anderen Platten komplett gelesen werden, was für die Platten eine enorme außergewöhnliche Belastung darstellt. Die Chance, dass genau dadurch eine weitere Platte ausfällt, wär mir zu hoch.
Bisher ist einmal eine Platte kaputt gegangen, quasi direkt nach der Einrichtung.
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.
Christoph schrieb:
Xin schrieb:
Wichtige Daten solltest Du verschlüsselt(!) auf einen Netzwerkdienst legen - der muss nicht als "Cloud" vermarktet werden... Ich habe dafür einen VServer, den ich als Backup-Müllhalde von anderen Servern verwende - also auch von zu Hause.
Wenn man etwas nimmt, das als "Cloud" vermarktet wird, bekommt man halt deutlich mehr Speicher fürs selbe Geld als wenn man einen VServer nimmt. Ein VServer lohnt sich deswegen nur, wenn man den sowieso für andere Zwecke braucht, würde ich sagen.
Man braucht ja keinen VServer... das Ding kostet 5 Euro im Monat, dient als Testserver und Datenmüllhalde.
Es spricht auch nichts dagegen, sich ein Backup der wichstigsten Daten per Mail zu schicken und diese Mail solange auf dem Server zu belassen, bis man neue Backup-Mails auf dem Server hat.
Christoph schrieb:
Da es nur um ein privates NAS geht, halte ich die mögliche Downtime durch einen kaputten USB-Stick auch für vertretbar.
USB-Stick ist hier eine akzeptable Idee. Logging etc. nervt, wenn der USB-Stick langsam ist bzw. schnell kaputt geht.
Dafür eignet er sich gut als Schloss, wenn man das RAID verschlüsselt. Ohne Stick fährt die Kiste nichtmals hoch.Christoph schrieb:
RAID5 mit zwei redundanten Platten ist ein RAID6.
Keine Ahnung, ich glaube in Erinnerung zu haben, dass es da mehr Unterschiede gegeben hätte.
Kann aber sein, da - wie gesagt: keine Ahnung.
Das wird jedenfalls der nächste Schritt werden. Ich muss nur erstmal der Kiste verklickern, dass ich noch mehr SATA-Geräte anschließen will, die Startplatte ist nicht umsonst eine alte IDE.
Christoph schrieb:
Ist unberechtigt, denk ich. Ich hab schon häufiger von kaputten SVN-Repositories gelesen als von kaputten git-Repositories. Um genau zu sein, von kaputten SVN-Repositories hab ich schon gelesen, von kaputten git-Repositories noch nie.
Die Erfahrung eines kaputten SVN-Repositories besitze ich nicht und ich habe auf proggen.org Repositories und in der Firma laufen auch Repositories mit ich weiß nicht wieviel Gigabyte Größe, wo ich erster Ansprechpartner bin. Bisher läuft das alles zuverlässig.
Git löst teilweise Probleme, die ich nicht habe. Was bedeutet, dass es auch Fragen aufwirft, die ich im Job weder beantworten will, noch für die ich verantwortlich sein möchte.
Christoph schrieb:
Xin schrieb:
Ein selbst konfigurierter Server kann alles, was Du willst, ist billiger und Du musst selbst sehen, dass er läuft.
Und genau der letzte Punkt wird für den OP das KO-Kriterium sein, vermute ich.
edit: OK, ich kann aus den Postings nicht so gut herauslesen, in wie weit der OP Linux-Kenntnisse hat. Ohne Linux-Kenntnisse wird es sehr zeitaufwendig, ein NAS selber aufzusetzen. Vielleicht geht das auch mit Windows ganz gut, aber das weiß ich nicht.
Kein NAS läuft mit Windows
Christoph 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.[/quote]
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?
-
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
