RAID5 / URE / bad blocks / Sicherheit: Meine Gedanken und einige Fragen *viel Text*

[xirius]

Halo,

ich habe mir einige Gedanken zum Thema RAID und Datensicherheit gemacht und sie niedergeschrieben, dabei sind mehrere Fragen entstanden. Ich hoffe, der eine oder andere hat eine Antwort

Ich bin auf einige Text gestoßen, die die Sicherheit von RAID5 anzweifeln: Auf Grund der enormen Festplattengrößen heutzutage ist ein RAID5 nur noch "relativ" sicher, da bei einem Plattenausfall zur Wiederherstellung der kaputten Festplatte die Paritätsdaten von den verbliebenen Platten vollständig gelesen werden müssen. Da die Festplatten mittlerweile immer größer werden, ist es immer wahrscheinlicher, auf einen URE "Unrecoverable Read Error" zu stoßen.

1) Werden "nur" die Paritätsinformationen benötigt und ausgelesen oder Paritätsinformationen + die verbliebenen Daten? Dies hätte nämlich Auswirkung auf die folgende Rechnung, ich nehme erst einmal an "alle Daten werden benötigt".

Meine Platten: Samsung HD204UI SpinPoint F4 EcoGreen (2TB = 1862,65 GB in 1024 Konvertierung)
URE 1 / 10^15 bits

4 Platten, eine fällt aus -> 3 Platten mit je 2 TB zum Auslesen:

3 Platten * 2 TB * 10^12 byte/TB * 8 bit/byte = 48.000.000.000.000 bit = 48 * 10^12 bit = 48e12

p für URE ist 48e12 / 1e15 = 0,048 = 4,8% Warsch. für nicht mögliche vollständige RAID Wiederherstellung, da ein Bit nicht gelesen werden kann

1 / 0,048 = 20,83, somit ist es bei jedem 20x Plattenausfall nicht möglich, das RAID vollständig wiederherzustellen.

2) Ist die Rechnung korrekt oder ist da noch mehr zu beachten?

3) Wenn die vollständige Rekonstruktion auf Grund eines URE versagt, ist es doch aber möglich, das RAID weiterhin im "degraded mode" laufen zu lassen (wo die kaputte Platte entfernt wird und der RAID live beim Datenzugriff die fehlendes Informationen berechnet. (Stimmt das ?) So kann ich ein Datenbackup erstellen. Die Datei, die von dem "bad block" betroffen ist, wäre dann eben verloren. Alles andere aber nicht. Somit ist das ganze nicht so schlimm?

4) Könnte man hier bei der Rekonstruktion nicht einfach eine Annahme machen, z.B. dass das Bit "0" war (oder "1") und eine Rekonstruktion machen und schauen, ob "brauchbare" Daten dabei entstehen? Oder ist bei einem URE gleich ein ganzer Block (z.B. 4kb) betroffen?


5) Ich habe ein externes NAS Hardware-RAID (Fantec QB-35US3R mit JMicron Chip). Falls die Platine mal durchschmoren sollte oder sonstiges, kann man die Festplatten theoretisch nicht in einen PC einbauen und Softwareseitig mit Freeware/Komerziell die Rekonstruktion durchführen? Soweit ist das Verstehe, ist die "Parität" eine "einfache" XOR Rechnung, oder hat jedes Hardware-RAID seine eigene RAID5 Methode??

6) Was passiert, wenn ein URE auf einer normalen Systemplatte bei Betrieb auftritt? Z.B. habe ich eine Textdatei/ein Bild, was ich vor 3 Jahren erstellt und gespeichert habe. Jetzt öffne ich es und irgendwo in den Dateibits kommt es zu einem URE. Meine Vermutung: Die Festplatte merkt da "stimmt etwas nicht", markiert intern den Block dann als "badblock", was dann? Kommt es zu einem Bluescreen? (Das hatte ich bei einer Platte schon öfters, dass bei Zugriff auf eine ganz bestimmte MP3 das System immer hängen blieb, ein chkdsk /R zeigte dann tatsächlich, dass bei der Datei Sektoren defekt waren) Ist dann im Textdokument das eine Zeichen falsch dargestellt? Oder in dem Bild ist/sind dann ein paar Pixel falsch, was aber nicht auffällt?

7) Wie kann ich mich "schützen" vor unbemerktem Datenverlust? Ich möchte vermeiden, dass ich irgendwann merke, dass 1% meiner Fotos unbrauchbar geworden sind durch mir nicht aufgefallene bad blocks
Wäre ein halbjährlicher fsck bad blocks check sinnvoll?
Besser Checksummen der Datei erstellen und halbjährlich vergleichen ob noch alles beim alten ist?

8) Ich möchte mein NAS mit RAID5 4*2TB unter Linux betreiben: Es mit luks/dm-crypt verschlüsseln, dann ext4 Dateisystem erstellen:
mkfs.ext4 -b 4096 -E stride=32,stripe-width=96 -m 0 -L RAID [-cc] -v
Macht das "-cc" (Check the device for bad blocks before creating the file system. If this option is specified twice, then a slower read-write test is used instead of a fast read-only test.) hier Sinn? Es wäre doch gut im Vorraus einen Komplett Check zu machen, ob denn defekte Sektoren vorhanden sind. ABER: Funktioniert das Prüfen der defekten Sektoren in diesem Szenario mit transparenter dm-crypt Verschlüsslung auf einem USB 3.0 angeschlossenen Hardware RAID5??

9) Auf dem RAID werden nur große Dateien (~10-30GB) gespeichert und selten modifiziert. Mehr Lese- als Schreibzugriffe. Machen eine chunk-size von 128kb (Parameter stride=32,stripe-width=96) Sinn? (If the chunk-size is 128 kB, it means, that 128 kB of consecutive data will reside on one disk.) Macht das Performancetechnisch Sinn bei großen Dateien?

Falls es jemand bis hier unten geschafft hat, vielen Dank

 

[Masamune2]

1.) Zum Wiederherstellen des Raids müssen bei einem klassichen RAID alle Daten gelesen werden. Nur die Paritätsblöcke würde nicht reichen. Dein Gedankengang ist soweit also korrekt und es gibt diverse Beiträge im Internet zu genau dem Problem. Um das ganze zu umgehen gibt hauptsächlich zwei Ansätze:

- Mit Raid 6 hast du eine weitere Parität die das Risiko mindest. Tritt hier nach dem Ausfall einer Platte ein Lesefehler auf kann über die verbleibende Parität der Fehler erkannt werden.
- Die Raid Funktionalität wird Bestandteil des Dateisystems wodurch zusätzliche Prüfsummen und Fehlerkorrekturmechanismen eingebaut werden können.

In der Regel läuft es auf beides hinaus da man so den Fehler sehr sicher erkennen (zusätzliche Prüfsummen) und dann auch beheben kann (Raid 6).

3.) Das kann man natürlich immer machen. Mit Tools wie ddrescue kann man Daten ohne Rücksicht auf Lesefehler kopieren, mit etwas Glück ist nichts wichtiges kaputt gegangen. Hier kann Ernst sicher mehr sagen.

4.) Das wäre in der Praxis kaum möglich da man dazu einen kompletten Chunk des Raids erraten müsste.

5.) Ja auch dafür gibt es entsprechende Tools. Die Raid Berechnung ist bei Raid 5 ein XOR, allerdings speichern die Controller von Hersteller A ihre Metadaten und die Config nicht unbedingt so wie Hersteller B daher muss man da schon wissen wo man ansetzen muss.

6.) In der Regel überlegt Windows dann mal 60 Sekunden bzw. wartet auf die Rückmeldung der Platte und meldet dann das vom Datenträger nicht gelesen werden kann. Da sich Windows bzw. die Platte die Daten dann nicht einfach ausdenkt hast du dann keine falschen Zeichen im Bild sondern es ist schlicht nicht lesbar. Hier gilt "ganz oder gar nicht".

7.) Du könntest MD5 Hashes deiner Daten erstellen (dafür gibts zahlreiche Tools) und die regelmäßig mal checken. In der Praxis kenne ich niemanden der das wirklich tut denn die Chance das du wirklich mit der Zeit Daten verlierst ist doch relativ gering. Ansonsten natürlich immer ein Backup davon machen.

8.) Wenn du die Möglichkeit hast dann nutze ZFS für deine Daten. Das bietet eine erweiterte Fehlererkennung. Wohlgemerkt soweit ich weiß nur Erkennung! Sind wirklich mal Daten defekt müssen sie vom Backup zurück gespielt werden.

 

[Holt]

Du solltest das RAID nicht als Alternative für ein Backup auf einer anderen, möglichst externen HDD betrachten, denn nicht nur Plattenausfälle bedrohen die Daten und solche gegen Bedrohungen wie Viren oder auch einen Netzteilausfall der alle Platten auf einmal killt. hilft ein RAID eben nicht. RAIDs (mit Parity) erhöhen nur die Verfügbarkeit der Daten im Falle eines Ausfalls einer (oder bei RAID 6 zweier) Platten.

 

[xirius]

8.) Wenn du die Möglichkeit hast dann nutze ZFS für deine Daten.

Hi,
danke, da hast du mich auf einen tollen Gedanken gebracht. Da scheint wirklich alles drin zu sein, was ich möchte. Das externe Festplattengehäuse hat leider kein JBOD, sonst könnte ich gleich ZFS noch die RAID Funktionalität übernehmen lassen. Naja, fürs erste werde ich dann wohl das Gehäuse weiter mit RAID5 betreiben, aber als Dateisystem ZFS nehmen und monatlichen "scrubben"

@Holt
Das ist mir bewusst, doch noch einmal Backup Speicher für ~5-6 TB Daten zu kaufen wäre derzeit einfach nicht möglich für mich. Daher möchte ich fürs erste das beste aus der Situation machen. Kommt Geld, kommt ein zusätzlicher Speicher, der dann bei Oma unten im Schrank steht

 

[Ernst@at]

1) wenn von 133% Information (33% Redundanz) auf 33% wegen Ausfalls nicht mehr zugegriffen werden kann, wieviel muss ich dann lesen, um 100% Information zurückzugewinnen?

2) statistisch vielleicht, die Praxis sieht anders aus

3) kommt immer darauf an, wo der Fehler auftritt, ob und wie er behoben werden kann. 4K Verlust auf einem 6TB Array kann essentiell oder völlig unwesentlich sein. Beinhalten diese 4K den Encryption-Key, und davon ist kein Backup vorhanden: 100% Verlust. Liegen diese 4K in einem unbenutzten Bereich: 0% Verlust. Ist der Index einer Datenbank betroffen, wird das größere Nachteile haben als beim Verlust einiger Pixel einer Videodatei.
Onboard-RAID-Controller schmeissen in so einem Fall die Nerven weg und setzen das ganze Array offline,
echte RAID-Controller kennzeichnen diese Defektstelle und melden nach Rekonstruktion bei Zugriff auf einen der betroffenen Bereiche dann einen Lesefehler.

4) Je nach verwendeter Aufzeichnungstechnologie der Platten sind es 512B oder 4KB. Ist der defekte Block x der intakten Platte ein Parity-Block, so kann der Block x der ausgefallenen nicht rekonstruiert werden. Ist der Block x der intakten ein Datenblock, so ist dieser verloren; liegt auf der ausgefallenen ebenfalls an der Stelle x ein Datenblock, dann ist auch dieser verloren. Ein Lesefehler liegt vor, wenn der Inhalt nach mehreren Versuchen selbst mit Hilfe des auf der Oberfläche gespeicherten ECC nicht rekonstruierbar ist. Dann wird der Inhalt auch nicht über die Schnittstelle übertragen. In diesem Fall kann weder festgestellt werden, wo innerhalb des Blockes der Fehler liegt noch wieviele Bits betroffen sind(heutige ECC-Verfahren sind in der Lage, viele falsche hintereinander- oder verstreut liegende Bits innerhalb eines Blockes zu korrigieren).

5) Ja, einige Tools sind dazu geeignet, auch den speziellen Aufbau des Arrays von NAS-Platten rekonstruieren zu können.

6) ein I/O Error. Je nach Lage des fehlerhaften Blockes und der davon betroffenen Datei und der programmtechnisch vorgesehenen Reaktion auf so ein Ereignis schlägt sich das vom Bluescreen/Systemrestart bis zur Frage, ob der Zugriff wiederholt/der Fehler ignoriert werden soll, nieder.

7) Backup in mehreren Generationen und an unterschiedlichen Aufbewahrungsorten.
Murphy's Law in Kombination mit dem Fehler, der vor dem Bildschirm sitzt und unkontrolliert Tasten drückt, kann auch bei ungesichertem RAID-überdrüber jederzeit zu 100%igem Datenverlust führen

8) Ein Überprüfen der Einzelplatten(mehrfaches vollständiges Beschreiben und Leseprüfung) mit entsprechenden Tools ist da die weitaus effizientere Methode.

9) Bei einem RAID5 mit 4 Memberplatten lässt sich performancetechnisch ohnehin kaum was hinter dem Ofen hervorlocken, beim Lesen und einem NAS ist es eher nebensächlich. Trotzdem gilt: Je größer, desto Flutsch.

Bitte.

 

[Holt]

Performance und JMicron (nicht mit Micron ohne J verwechseln, ist eine ganz andere Firma!) passen sowieso nicht zusammen, denn von deren Controllern war noch nie einer irgendwie besonders performant. Die können nur billig, aber für ein NAS reicht es, dann mehr als so 130MB/s Daten gehen nun einmal wirklich nicht über ein Gigabyte Netzwerk und das schaffen auch die JMicron RAID Chips noch, aber eben auch nicht so viel mehr.