staging.inyokaproject.org

Das ist quatsch, wenn die Festplatte beim SMART schlechte Werte zeigt wird sie ausgetauscht, dafür hat man schließlich das Raid. Die eventuell fehlerhaften Daten auch noch auf die sauberen Disks zu replizieren ist doch Selbstmord.

Hmmm, Du bist Dir also sicher, daß das RAID dann wieder hergestellt werden kann?

Ich hatte auf zwei Platten defekte Sektoren. Wenn es z.B. ein RAID1 aus zwei Platten ist und ich ersetze eine Platte. Wie kann dann das RAID wieder hergestellt werden?

Außerdem: warum sollen fehlerhafte Daten repliziert werden? In der Doku wird die Operation als save beschrieben. Durch die Überprüfung kommen Fehler erst zum Vorschein.

BTW - dieser Schwachsinn wird von Ubuntu per cronjob einmal im Monat gemacht (bei mir ist das nie vollständig passiert, weil mein Server nicht durchläuft). Dann sind Ubuntu-Entwickler ziemlich blöd?

Es gibt inzwischen auch ein "Bad Block Log" (aber nur mit aktuellem mdadm auf default-an, bei älteren muss man es erst mit --update=bbl hinzufügen) mit dem Platten trotz defekter Sektoren nicht sofort aus dem RAID gekickt werden.

Bei einem RAID1 kannst du auch eine dritte Platte hinzufügen. So kannst du dann einen Sync herstellen auch wenn die anderen Platten nicht korrigierbare Defekte haben (solange es nicht zu viele sind und an verschiedenen Stellen).

Fehlerhafte Daten sollte es idealerweise nicht geben (nach einem check sollte der RAID mismatch_cnt = 0 sein). Eine Festplatte liefert entweder Lesefehler oder aber das RAID selbst schreibt die korrekten Daten zurück. Das funktioniert im allgemeinen auch sehr gut. Richtig Probleme bekommt man nur wenn man am RAID vorbei schreibt, also hdparm (mit u.a. den sector write/repair Optionen) oder badblocks (nondestructive readwrite) und dergleichen ist tabu, da ist ausschließlich der RAID check/repair zu verwenden.

Natürlich gehört eine unzuverlässige Platte sofort ausgetauscht, um das zu bemerken muss man aber eben die Platten überprüfen. Und wenn man das versäumt hat und dann schon mehrere Platten angeknackst sind muss man eben schauen wie man das wieder hinbekommt...

@frostschutz Genau so sehe ich das auch. Bei mir sind die Fehler bis zum Check mdraid nicht aufgefallen. Ich habe ein RAID5.

Ich sehe halt folgende offene Frage: bei Plattenfehler soll man laut allgemeiner Meinung die entsprechende Platte so schnell wie möglich wechseln. Tut man das, besteht die Gefahr, daß das RAID nicht wieder hergestellt werden kann, weil eine weitere Platte defekte Sektoren hat. In Summe der alten Platten ist das RAID aber noch voll funktionsfähig.

Ich habe im Internet länger gesucht, was man da machen kann. Da gibts Anleitungen, wie man die Vorgehensweise des Bad Block Howto auf ein RAID anwendet (modifizierte Sektorberechnung). Und das ist übler Unsinn, da macht man das RAID erst kaputt.

Wenn du eine defekte Platte hast, musst du sie so schnell wie möglich wechseln - das ist völlig richtig, denn je länger du wartest, desto wahrscheinlicher daß eine zweite Platte auch noch die Grätsche macht.

Ich mache vor einem Plattenwechsel keinen zusätzlichen Check. Die Checks laufen bei mir sowieso automatisch/regelmäßig, das nochmal machen wäre also redundant/Zeitverschwendung. In der Regel ist der Plattenfehler ja gerade bei einem solchen Check lokalisiert worden.

Probleme haben da nur Leute die kein richtiges Monitoring für ihre Platten haben, die Tests gehören eben dazu. Wer darauf verzichtet muß dann eben herausfinden wie gut die Backupstrategie war.

Daß Platten tatsächlich gleichzeitig Defekte entwickeln ist die absolute Ausnahme, in der Regel hat man alte Fehler einfach nur zu spät entdeckt.

rennradler schrieb:

Hmmm, Du bist Dir also sicher, daß das RAID dann wieder hergestellt werden kann?

Natürlich, dafür ist es konzipiert.

Ich hatte auf zwei Platten defekte Sektoren. Wenn es z.B. ein RAID1 aus zwei Platten ist und ich ersetze eine Platte. Wie kann dann das RAID wieder hergestellt werden?

Wenn beide defekt sind garnicht, dafür hast du ja die Backups.

Außerdem: warum sollen fehlerhafte Daten repliziert werden? In der Doku wird die Operation als save beschrieben. Durch die Überprüfung kommen Fehler erst zum Vorschein.

Zumindest wenn man Desktopplatten benutzt kann es passieren, das intern irgendwelche defekten Sektoren ausgetauscht werden und die Daten der alten Sektoren werden nur fehlerhaft in die neuen kopiert. Das Raid bekommt davon garnix mit. Und woher soll dein Raid 1 jetzt wissen auf welcher der beiden Platten die korrekten Daten liegen?

BTW - dieser Schwachsinn wird von Ubuntu per cronjob einmal im Monat gemacht (bei mir ist das nie vollständig passiert, weil mein Server nicht durchläuft). Dann sind Ubuntu-Entwickler ziemlich blöd?

Nein die sind recht intelligent und haben den Sinn eines Raids kapiert. Ein Server der extra ein Raid für hohe Datenverfügbarkeit bekommt wird ganz sicher nie ausgeschaltet. Ein Rechner der täglich ausgeschaltet wird, kann einfach beim Runter fahren ein Backup machen.

Ich sehe halt folgende offene Frage: bei Plattenfehler soll man laut allgemeiner Meinung die entsprechende Platte so schnell wie möglich wechseln. Tut man das, besteht die Gefahr, daß das RAID nicht wieder hergestellt werden kann, weil eine weitere Platte defekte Sektoren hat.

Tut man es nicht besteht die Gefahr dass schon am nächsten Morgen garnix mehr geht, dann braucht man erstmal neue Festplatten und muss noch mehrere TB Daten zurück spielen. Das sind dann wieviele Tage Ausfall? Es gibt übrigens auch Raid 6 oder Raid 1 über mehrere Platten, wenn einem ein Datenträger Redundanz nicht reicht.

stfischr schrieb:

Zumindest wenn man Desktopplatten benutzt kann es passieren, das intern irgendwelche defekten Sektoren ausgetauscht werden und die Daten der alten Sektoren werden nur fehlerhaft in die neuen kopiert. Das Raid bekommt davon garnix mit.

Selber Daten erfinden darf die Platte einfach nicht. Wenn eine Platte das macht hat man ein echtes Problem.

Solche Sektoren sollten erstmal Pending werden und erst bei Schreibzugriff dann ggf. reallokiert werden.

Dabei ist halt wichtig daß der Schreibzugriff über den RAID-Layer geschieht und nicht mit externen Tools (eben hdparm, badblocks, ...). Sonst hat man in der Tat falsche Daten von denen das RAID nichts weiß. Wenn das RAID selbst schreibt sind die Daten ja wieder korrekt, eben von der anderen Platte kopiert.

Sobald eine Platte zum RAID gehört ist das exklusiv. Direkter Zugriff auf die Platte von außen (auch von einer LiveCD aus) ist tabu, sonst ist das RAID eben kaputt.

Beim RAID-Check auf den mismatch_cnt achten. Wenn der nicht 0 ist...

Hallo alle!

Software-Raid mit mdadm ist eine feine Sache. Allerdings war mir persönlich die vorhandene Dokumentation an vielen Stellen zu ungenau. Beim Umsetzen einiger Lösungen bin ich immer wieder an verschiedenen Stellen gescheitert. So das ich mich dazu entschloss eine eigene Dokumentation zu schreiben. Es ist eine sozusagen Schritt-für-Schritt Anleitung - nahezu 100% DAU sicher. Da diese Lösung wirklich gut geworden ist möchte ich euch diese jetzt hier vorstellen. An die Anpassung des Wiki-Artikels habe ich mich nicht getraut - gern könnt ihr Teile meiner Dokumentation übernehmen.

Hier nun der Link:

Software Raid mit mdadm (für NAS-Server): http://ctaas.de/software-raid

Noch ein letzter Hinweis: Es werden keine Boot-Systeme behandelt. Es geht hier also eher um ein extra RAID-Verbund in einem NAS mit extra boot-Speichermedium.

Ich hoffe das ist so ok. Falls nicht dann löschen.

PS: Die Darstellung der Dokumentation wurde möglichst für alle erdenkliche Systeme optimiert, sie ist immer perfekt lesbar - egal ob PC, Smartphone, Tablet oder Drucker. Neuere Ubuntu-Versionen und kompatible Systeme wie z. B. Linux Mint oder Raspberry werden auch unterstützt (Ubuntu basierende Systeme).

supersach!

Silent-PC schrieb:

Es werden keine Boot-Systeme behandelt. Es geht hier also eher um ein extra RAID-Verbund in einem NAS mit extra boot-Speichermedium.

diesen Hinweis wuerde ich in's Intro deines howtos einfuegen

Hallo,

hab's mal am Ende des Artikels unter "Links" verlinkt.

Sinnvolle Links dürfen in der Sektion "Links" eines Artikels immer und ohne Rückfrage hinzugefügt werden ☺

Gruß, noisefloor

Silent-PC schrieb:

Allerdings war mir persönlich die vorhandene Dokumentation an vielen Stellen zu ungenau.

Da fehlt allerdings noch etwas. Ich spreche da aus gerade gemachter Erfahrung! 😈

Vor Umbauten das speichern:

mdadm --examine --scan --verbose

Insbesondere die Reihenfolge der Disks ist da uU wichtig.

Wurde das Array zerschossen (zB wegen Controller-Defekt bei grow), und "mdadm --assemble --force" scheitert (auch mit "backup-file" und "invalid-backup"), dann hilft nur noch der schreibende Rettungsversuch:

mdadm --create --assume-clean --level=5 --raid-devices=3 /dev/md0 /dev/sdc1 /dev/sdd1 missing

"missing" deshalb, damit das RAID nicht sofort mit dem "recovery" beginnt.

Falls die o.g. Reihenfolge der Partitionen nicht stimmt, so erhält man beim mounten folgende Fehlermeldung hingeklatscht:

Couldn't mount because of unsupported optional features (1fd00001)

Dann darf man unterschiedliche Reihenfolgen probieren, bis der mount klappt.

Dicke Warnung nicht vergessen, dass "create" wirklich der allerletzte Rettungsanker sein sollte.

pepre schrieb:

Dicke Warnung nicht vergessen, dass "create" wirklich der allerletzte Rettungsanker sein sollte.

Man sollte mdadm --create gar nicht zur Rettung hernehmen oder jedenfalls nicht so, wie du es geschrieben hast. Da gehört dann ggf. noch einiges mehr dazu (Plattenreihenfolge, Offset, Chunksize, Metadatenversion, ...). Auf Standardwerte in mdadm kann man sich da auch nicht verlassen da die sich immer wieder ändern. Man muss sich da an mdadm --examine halten.

Und für solche Experimente vielleicht auch lieber mit Overlay: https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file

Damit sind die Schreibzugriffe nur "virtuell" und damit umkehrbar...

frostschutz schrieb:

Da gehört dann ggf. noch einiges mehr dazu

Full ack, s. https://raid.wiki.kernel.org/index.php/RAID_Recovery.

Und für solche Experimente vielleicht auch lieber mit Overlay

Oder man hat mit dd die relevanten HDs geklont. ☺

Aber du hast Recht: muss man am "offenen RAID" operieren, so ist Overlay Pflicht.

Man muss sich da an mdadm --examine halten

Wie ich leidvoll erfahren musste: es gibt Situationen, da gibt "examine" nur Quatsch aus. 😀

Hab ich gerade geschrieben, weil ich nicht nochmal in so ein Desaster reinschlittern will:

#!/bin/bash

echo "### mdadm --examine --scan --verbose"
mdadm --examine --scan --verbose
echo " "

echo "### cat /proc/mdstat"
cat /proc/mdstat
echo " "

echo "### mdadm --detail /dev/md0"
mdadm --detail /dev/md0
echo " "

echo "### lsscsi"
lsscsi
echo " "

echo "### blkid"
blkid
echo " "

echo "### Serials"
for TMP in $( lsscsi | awk '{ print $NF }' ) ; do echo -n "$TMP:  " ; smartctl -a $TMP | grep Serial ; done
echo " "

Diese Infos sollte man für Notfälle parat haben.

Könnte man auch in den Artikel packen.

Das scheint mir ein wichtiger Artikel zu sein – er ist aber derzeit nur für Precise getestet. Kann jemand überblicken, ob er so (vollständig) auch für Xenial gilt? (Ich vermute, dass ja – kann das aber nicht wirklich beurteilen. Der Hinweis auf die IDE-Festplatten erscheint mir aber auf jeden Fall überflüssig, da diese vermutlich niemand mehr für ein RAID verwenden würde?)