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
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