Norbert_Focus schrieb:
Vorweg, ich kenne die These "ein Raid ist keine Datensicherung", also bitte keine Belehrungen diesbezüglich.
Als These bezeichnen das meist nur Leute die es noch nicht selbst erfahren mussten, aber Du speicherst ja auch noch Backups Deiner Daten auf USB Platten, damit hast Du ja dann eine Datensicherung.
Norbert_Focus schrieb:
Im Moment nutze ich ein WD Book Studio Edition ... Die Daten auf den Platten werden im normalen Format ( ich glaube NTFS ) abgespeichert
Das ist ja auch nur eine USB Platte, da verwaltet der PC das das Filesystem, das ist Gehäuse ist dumm und der Chip darun übersetzt nr zwischen USB und SATA. Die WD haben aber auch gerne dann eine Datenverlüsselung aktiviert, wenn man da selbst nicht getan hat und auch kein Passwort eigeben muss, dann kommt man bei einem Ausfall des Gehäuses aber eben meist nicht mehr an die Daten.
Norbert_Focus schrieb:
Ich würde mir gerne ein 4bay NAS mit 16TB kaufen, hätte also im Raid1 8TB zum beschreiben.
Also entweder nimmst Du dann zwei 8TB HDD im RAID 1, aber nicht die Seagate Archive v2, die hat SMR und ist nicht für NAS zu empfehlen, oder eben vier 4TB im RAID 10.
Norbert_Focus schrieb:
oft liest man dass die NAS Systeme eigene Dateisysteme haben die man mit Windows nicht auslesen kann.
So ist, aber das kommt erst zum Tragen, wenn man sie aus dem NAS ausbaut, im NAS und übers Netzwerk merkt man vom Filesystem nichts und kann sie praktisch wie normale Windows Laufwerke zu verwenden.
Norbert_Focus schrieb:
Im Fall eines defekts des Rechners im NAS Gehäuse käme man nicht mehr an die Daten.
Genau dafür gibt es eben Backups, egal ob die Daten auf einem RAID stehen oder nicht. Stell Dir vor das NAS wird vom einem Verschlüsselungsvirus infiziert (gab es auch schon), das Netzteil des NAS macht den Abgang und nimmt die Platten mit oder das NAS Gehäuse fällt runter und alle Platten darin sind hin. Dann gäbe es noch Wasserschäden (ggf, durch Löschwasser bei einem Feuer), Diebstahl, etc. pp. oder einfach nur das versehentliche Löschen der Daten durch den User, alles Risiken vor denen RAIDs nicht schützen, nicht nur in These nicht.
Norbert_Focus schrieb:
Idealerweise hätte ich also gerne ein NAS wo ich im Extremfall die Platten einfach ausbaue und per SATA Adapter an meinen PC anschliessen kann und dort auslese.
Die meisten NAS unterstützen NTFS für die externen Platten an den USB Ports, die sind eben genau dafür gedacht dort Backups zu machen und dann kann man diese Backupplatten auch bei einem Ausfall des NAS problemlos am PC auslesen.
Luxuspur schrieb:
Nen RAID funktioniert nunmal meistens nur an dem selben Controller ... anderer Controller und die Daten sind futsch!
...
Deswegen ist es auch empfehlenswert nen extra Controller zu verwenden, den kann man dann mit ins neue System nehmen
Das ist so ein grober Blödsinn, wann hört der Aberglaube endlich auf? Schau mal
in diesen Thread im Datenrettungsforum, da wurde ein Intel Chipsatz-RAID 0 mit Linux ausgelesen, denn der
Linux mdadm kann auch mit den Metadaten von Intel RAIDs umgehen:
Und nicht nur damit:
Luxuspur schrieb:
oder halt nen NAS wo in den Serien die gleichen Controllerchips verwendet werden, da ist die Chance am größten.
Die NAS haben eigentlich immer nur einen HBA und keinen RAID Controller und machen SW-RAIDs. Die mit den Marvell ARM CPUs nehmen meist den Marvell 9125 dafür, bei Intel CPU sind es die Ports der Chipsätze / SoCs.
Das Problem ein bestehendes RAID in einem anderen NAS laufen zu lassen ist meist nicht das RAID selbst, wie gesagt sind RAID sehr, sehr viel portabler als der Volksmund es glaubt, sondern die FW (also das OS) und die Aufteilung der Platten / RAIDs auf diesen diese i.d.R. eben installiert wird. Passt die nicht oder erwartet das andere NAS auch eine andere Aufteilung, dann klappt es mit der Übernahme des RAIDs nicht.
Noxman schrieb:
Ein RAID1 ist nichts anderes als ein Spiegel.
Nein, denn je nachdem ob die Metadaten des RAID am Anfang oder Ende der Platten stehen, beim mdraid unter Linux ist z.B. beides möglich, kann man am Anfang auch einen Offset haben und die Partitionstabelle etc. stehen dann eben nicht an der erwarteten Stelle ganz am Anfang der Platte, sondern erst hinter dem Superblock mit den Metadaten des RAIDs. Ohne das RAID welches diesen Offset abrechnet, kann man dann mit einer einzelnen Platte nichts anfangen.
Eine andere Sache ist, dass SW-RAIDs und RAID Controller wenn sie ihre Sache ernst nehmen, ein RAID als Volumen begreifen dessen Daten konsistent sein müssen. Wurde dann ohne eine der HDDs schon auf das RAID geschrieben, beim Booten passiert das bei jedem OS schon wegen der logs, dann hat man ein Problem wenn man einfach die Platten tauscht. Ich weiß nicht mehr ob hier oder in einem anderen Forum, aber irgendwo war mal ein Thread, da hatte einer einen hochwertigen RAID Controller und zwei Platten im RAID 1 und hat sich beschwert, dass es nicht funktionieren würde. Er hat folgenden Test gemacht:
1. RAID 1 eingerichtet und (meine ich) Windows installiert
2. HDD 1 abgezogen und getestet, Windows hat normal gebootet, wurde wieder runtergefahren.
3. HDD 1 wieder eingesteckt und dafür HDD 2 entfernt.
4. Rechner hat nicht gebootet und darin hat er einen Fehler gesehen.
Das war aber kein Fehler, das war ein Profi-RAID Controller und kein Billig-Spielzeug RAID Controller, der einfach nur spiegelt. Der Profi-RAID Controller hat gemerkt, dass das RAID nach den Abziehe von HDD 1 degradiert war und da sein Inhalt überschrieben worden ist, weil Windows wie jedes OS ja auch Logs führt und damit immer auch auf sein Systemlaufwerk schreibt. Damit entsprechen nur noch die Daten auf HDD2 den aktuellen Zustand des RAIDs. Durch den direkten Tausch der beiden HDDs gab es nun diesen aktuellen Zustand nicht mehr, da die HDD2 auf der er gespeichert war, ja nicht eingebaut war und HDD1 die letzten Änderungen nicht kannte, der Controller hat das RAID also als defekt gesperrt und das war richtig.
Warum war es richtig? Nun hier hätte bei einem einfach RAID Controller der sowas nicht beachtet und wie der Type sie wohl auch nur kannte, der Rechner auch im Schritt 4 gebootet, eben ohne die Änderungen vom letzten Booten, den z.B. den Eintrag Windows hat um 11:30 gebootet der nur auf HDD2 stand. Dann wäre auf HDD 1 nun z.B. 11:45 als letzter Zeitpunkts des Bootens vermerkt. Was kommt raus, wenn man nun beide HDD bei so einem RAID wieder einbaut? Hängt davon ab, ob die Datei von der einen oder von der anderen Platte gelesen wird. Die Daten stimmen auch beiden Platten nicht überein und das fällt bei solche Billiglösung auch nicht gleichen auf, den RAID lesen immer nur von einer Platten und erst wenn es dort einen Lesefehler gibt, von der anderen. Beide Daten sind aber korrekt lesbar, weichen aber voneinander ab und das darf eben bei Enterprise RAIDs nie passieren, da können wichtig Daten drauf liegen und bei einem Abgleich kann dann auch nicht mehr sagen, welche korrekt sind.
Daher wäre der korrekte Test in dem Fall gewesen, den Schritt 3. so zu gestalten, dass man erst die HDD 1 wieder einfügt, dem RAID Controller Zeit gibt das Resync der Daten von HDD 2 auf HDD 1 abzuschließen und dann erst HDD 2 zieht. Dann hätte HDD 1 den korrekten Datenstand des RAIDs enthalten und es hätte funktioniert. Hoffentlich wurde nun verständlich was ich damit sagen will, wenn ich sage, dass ein RAID eben ein logisches Volumen und mehr als nur die Summe der Platte ist und wieso es gut ist, wenn ein Controller das auch so handhabt.
Noxman schrieb:
Auf beiden Platten wird somit der gleiche Datenstand abgebildet. Daher sind die Platten auch im Havariefall lesbar.
Ja, nur eben unter Umständen nicht einfach so ohne das RAID und wenn diese Platte vorher schon aus dem RAID geflogen ist und daher nicht den letzten Stand des RAIDs enthällt und die andere dann aufällt, dann u.U. sogar nicht einmal mit dem RAID.
