Heimische Dokumenten und Backup Speicherlösung?
-
Achtung, langer Post. Hoffe, dass er (trotzdem) irgendwie hilfreich ist.
David W schrieb:
Ich hätte aber noch folgefragen, (wenn ich daraus Separate Threads machen soll mögt jemand bescheid sagen ^^)
Passt schon.
Wenn ich also ein NAS ohne W-LAN nehme, kann ich da trotzdem Pakete Installieren?
Bei den Synology-Geräten auf alle Fälle. Bei den QNAPs, die Dravere empfohlen hat, auch.
Ich habe gelesen das es auch NAS Weboberflächen gibt wo man kein Terminal hat, kann man bei diesen auch Pakete installieren und einrichten?
Die Synology-Geräte bedient man auch fast ausschließlich per Webinterfaces, nur zum Pakete installieren wirft man teils das Terminal und SSH an.
Pakete Installieren wäre das einzige wo ich W-Lan brauchen könnte. Ich hab aber ein D-Link W-Lan Stick da (hängt am Desktop PC), kann ich einfach anstöpseln?
Auf den Stick würde ich mich – weder bei Synology noch bei QNAP – nicht uneingeschränkt verlassen. Die Treibersituation mit USB-WLAN-Sticks ist notorisch unzuverlässig unter Non-Windows-Betriebssystemen.
Dravere schrieb:
David W schrieb:
Beeinträchtigt das nicht die Lebensdauer der Festplatten?
Ich gebe zu, dass meine Serverkenntnisse nicht gerade hervorragend sind. Allerdings bin ich hier der Meinung, dass genau das Umgekehrte der Fall ist. Ich habe in das NAS zwei Desktopfestplatten verbaut. Diese sind nicht für den Dauerbetrieb geeignet und somit darauf ausgelegt, dass sie ein- und ausgeschaltet werden. Das spart im übrigen auch etwas an Kosten. Serverfestplatten kosten schnell mal 50-200% mehr.
Um die Lebensdauerdifferenzen von "ein- und ausschalten" vs. "durchlaufen lassen" würde ich mir keine Sorgen machen. Tendentiell ist "durchlaufen lassen" wohl schon etwas günstiger, aber ich habe keine direkt vergleichbaren Daten und selbst wenn es messbare Unterschiede gibt, würde ich das NAS einfach nachts herunterfahren lassen. Besonders wenn die Box in meinem Schlafzimmer steht.
Die Frage von Serverfestplatten vs. Desktopfestplatten kann ich euch ganz kurz und prägnant beantworten: Zahlt bitte nicht mehr Geld für Festplatten die "für Dauerbetrieb geeignet" sind. Die Dinger sind ihr Geld einfach nicht (mehr) wert. Ich kann das gerne auch ausführlicher beschreiben, aber im wesentlichen läuft es darauf hinaus, dass Serverfestplatten heutzutage genauso unzuverlässig wie reguläre Desktop-Disks sind. (Sogar die Qualitätssicherung ist genauso schlecht. Ich habe gerade erst vor einem halben Jahr eine komplette Lieferung richtig teure Serverdisks zurückgeschickt, weil zwei gar nicht erst anliefen, vier beim Schreiben IO-Errors in bestimmten Bereichen produzierten, bei zweien der Relocated Sectors-Count bei jedem badblocks-Durchlauf anstieg und bei drei weiteren zcav gröbere Transferrateneinbrüche in bestimmten Bereichen zeigte.)
Der einzige verbleibende echte Unterschied sind die meist kürzeren Timeouts von Serverdisks, womit man im Betrieb mögliche Fehler schneller bemerken soll. Aber die sind den Aufpreis einfach nicht Wert.
David W schrieb:
Bei den Festplatten dachte ich an NASWare platten. K.A. wie das bei denen ist. (Da scheint es irgendwie bei "Red" und "Green" unterschiedlich zu sein)
Die NASWare-Dinger sind hoffnungslos überteuert.
Ich würde an deiner Stelle einfach die günstigsten (EUR/GB) Disks, die du findest, kaufen. Je nach Lautstärkeempfindlichkeit und Verfügbarkeit entweder 7200rpm oder 5400rpm. (Letztere sind seit diesen bösen Überschwemmungen in Thailand leider etwas schwerer zu bekommen, aber in der Regel etwas leiser und die Zugriffszeiten sind für dich ja nicht unbedingt alleroberste Priorität.)
Ach ja, irgendjemand wird dir garantiert bestimmte Hersteller ein/ausreden wollen oä. weil die ja so viel zuverlässiger sind, blablabla. Vergiss das. Disks fallen aus. Disks von allen Herstellern. Dass meine zwei Seagates zuhause noch leben sagt statistisch überhaupt nichts. Wir haben in der Arbeit ein paar ziemlich große SATA-RAID-Arrays und da gibt es bei den Ausfallsraten keine signifikanten Unterschiede zwischen den verbauten Marken.
-
Xin schrieb:
Für Fotos/Familienvideos würde ich über ein RAID5 nachdenken (4 oder mehr Festplatten) und nichts unterhalb von 2TB verbauen.
Bloß kein RAID5 mehr heutzutage. Die Restore-Zeiten bringen dich bei den heute üblichen Arraygrößen um und die Wahrscheinlichkeit, dass beim Restore eine zweite Disk stirbt, die dir dann das ganze Array mit in den Tod reißt, ist erschreckend hoch.
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.
Und: Falls David W nicht mehr als die ~3TB braucht, die man heutzutage halbwegs leistbar bekommt, würde ich ein stinknormales RAID1 mit 2 Disks fahren.
Außerdem sollen die Festplatten kühlen, Datensicherheit nutzt ja nix, wenn die Platten im Betrieb garen.
Die Bedeutung der Temperatur von Festplatten wird stark überschätzt. Siehe dazu auch Failure Trends in a Large Disk Drive Population (Google). In der Regel wird die normale Gehäusekühlung völlig ausreichen.
4x2TB dürften derzeit für um die 300 Euro zu haben sein
2TB-Disks bekommst du derzeit nicht für unter 90€.
Ich würde auch nur soviele Disks wie nötig nehmen. Wenn du mit zwei Disks auskommst, kauf einstweilen mal auch nur zwei. Zusätzliche dazuhängen kannst du später immer noch.
Wenn sie den ersten Monat überstehen normalerweise zwischen 5 Jahren und ewig.
Man sagt, man sollte sie alle drei Jahre wechseln.Drei Jahre ist nicht unrealistisch. Sobald die Dinger in Sachen SMART-Errors auffällig werden, sollten sie auf alle Fälle ausgetauscht werden wenn dir deine Daten etwas wert sind. Neue Disks kosten wenig, kaputte Daten sind meist teuer oder zumindestens unangenehm.
-
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.
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. Man lagert alle PCs auf dem RAID aus, aber das RAID mal eben auszulagern geht erst, wenn man das nächst(größer)e RAID aufbaut und die 4x2 reichen mir noch.
Für das nächste RAID werde ich mich da aber nochmal in Richtung RAID 6 schlau machen. Hast Du da informative Links?
nman schrieb:
Außerdem sollen die Festplatten kühlen, Datensicherheit nutzt ja nix, wenn die Platten im Betrieb garen.
Die Bedeutung der Temperatur von Festplatten wird stark überschätzt. Siehe dazu auch Failure Trends in a Large Disk Drive Population (Google). In der Regel wird die normale Gehäusekühlung völlig ausreichen.
Die normale Gehäusekühlung in einem NAS ist aber eben nicht immer leise.
nman schrieb:
4x2TB dürften derzeit für um die 300 Euro zu haben sein
2TB-Disks bekommst du derzeit nicht für unter 90€.
Einigen wir uns auf die Mitte: Auf die Schnelle fand ich 83 Euro, das sind 328 Euro für 4 Stück.
Ich hab vor drei Jahren noch 300 Euro für vier bezahlt und dachte der Tsunami wäre nun langsam erledigt.
nman schrieb:
Wenn sie den ersten Monat überstehen normalerweise zwischen 5 Jahren und ewig.
Man sagt, man sollte sie alle drei Jahre wechseln.Drei Jahre ist nicht unrealistisch. Sobald die Dinger in Sachen SMART-Errors auffällig werden, sollten sie auf alle Fälle ausgetauscht werden wenn dir deine Daten etwas wert sind. Neue Disks kosten wenig, kaputte Daten sind meist teuer oder zumindestens unangenehm.
Smart-Warnings sind meistens einfach Temperatur-Warnings etc. Festplatten mit Fehlern benutze ich z.B. für Videoaufzeichnungen, Fernsehsendungen aus der Mediathek oder ähnliches.
Bei wichtigen Daten gibt es eine Wanderfestplatte, die ich bei meinen Eltern einlagere. Ganz wichtige Daten - meine Quelltexte - werden als Archiv verschlüsselt und auf dem Backup-Server kopiert, den ich eigentlich für die automatischen Backups von proggen.org sowieso brauche und zusätzlich trage ich sie auf einem Mini-USB-Stick im Portemonnaie mit mir rum.
Solange ich also nicht abbrenne, das Rechenzentrum explodiert und ich bestohlen werde, sind meine Daten zeitnah wieder herzustellen, eventuell verliere ich ein paar Tage, aber eben nicht mehr. Sollte das doch passieren, verliere ich eventuell ein paar Monate, sofern meine Eltern drei Dörfer weiter nicht auch abbrennen.
Das dürfte für private Daten reichen.
-
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.
