Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 8.859
Der Thread dient als Doku und hat Längen. TLDR: Raid5 aus 6 HDDs via mdadm ist kaputt. Es gibt jetzt 2 Gruppen a 3 HDDs mit abweichendem Eventcount, eine HDD ist wahrscheinlich defekt. Mit der Info reicht es wahrscheinlich, den Thread ab jetzt von unten nach oben zu lesen..
Moin,
der Threadtitel wäre besser, würde mir etwas einfallen
.
Kurz und Knapp main raid5 aus 6 Platten mit BTRFS als Dateisystem ist beim Schreiben einer größeren Datenmenge ausgestiegen und hat den ganzen Rechner mitgerissen. Die Kiste wollte erst wieder booten, als in /etc/fstab nicht mehr versucht wurde das entsprechende Dateisystem einzuhängen.
SMART als Kurzzusammenfassung
Ich würde das Raid nun gern wieder in Betrieb nehmen, im vollem Bewusstsein, dass ich mindestens eine HDD, besser jedoch 3 kurzfristig tauschen sollte. Das Einhängen von /dev/md0 scheitert selbstverständlich. Zum einen ist das entsprechende Raid "inactive" und zum Anderen sind alle Platten als Spare (das S in Klammern) markiert anstatt als aktive Member. Also hab ich mal geschaut was mdadm mit den vorhandenen Platten anfangen kann:
Das ist jetzt nicht so prall und meine Frage ist, wie mache ich aus diesem Zustand wieder ein funktionierendes Raid5 mit möglichst minimalem Datenverlust?
Edit;
cat /proc/mdstat schaut jetzt natürlich so aus:
journalctl enthält nur Einträge nach 18.43, was der Zeitpunkt nach dem Ausfall des Raids / Systemabsturzes ist. -.-
Moin,
der Threadtitel wäre besser, würde mir etwas einfallen
.Kurz und Knapp main raid5 aus 6 Platten mit BTRFS als Dateisystem ist beim Schreiben einer größeren Datenmenge ausgestiegen und hat den ganzen Rechner mitgerissen. Die Kiste wollte erst wieder booten, als in /etc/fstab nicht mehr versucht wurde das entsprechende Dateisystem einzuhängen.
Code:
> sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Raid Level : raid0
Total Devices : 6
Persistence : Superblock is persistent
State : inactive
Name : amd-server:0 (local to host amd-server)
UUID : 3fe763fa:91cfd832:65bc079b:52e3fbde
Events : 11575
Number Major Minor RaidDevice
- 8 97 - /dev/sdg1
- 8 81 - /dev/sdf1
- 8 49 - /dev/sdd1
- 8 33 - /dev/sdc1
- 8 17 - /dev/sdb1
- 8 1 - /dev/sda1
Code:
> cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : inactive sdc1[2](S) sdb1[1](S) sdd1[3](S) sdg1[5](S) sdf1[4](S) sda1[0](S)
17580804096 blocks super 1.2SMART als Kurzzusammenfassung
Code:
sda -> in Ordnung
sdb ->alte Platte mit hoher Anzahl an Raw Read Error und Seek Errror, die Werte sind stabil und stammen von vor einem Jahr als ein Sata Kabel nicht richtig steckte. (Nach Austausch auf ein besser fixierendes Kabel keine Änderung der Werte). Keine schwebenden / reallokierten Sektoren. Damals waren die HDDs noch nicht als Raid konfiguriert.
sdc->Betriebsstunde 17 von 490 hat hat mehrere Sektoren reallokiert (beim Aufbau des Raids wahrscheinlich), die HDD wird reklamiert. Keine Fehler protokolliert die mit dem Ausfall des Raids korrelieren
sdd-> in Ordnung
sdf-> siehe sdb
sdg-> in OrdnungIch würde das Raid nun gern wieder in Betrieb nehmen, im vollem Bewusstsein, dass ich mindestens eine HDD, besser jedoch 3 kurzfristig tauschen sollte. Das Einhängen von /dev/md0 scheitert selbstverständlich. Zum einen ist das entsprechende Raid "inactive" und zum Anderen sind alle Platten als Spare (das S in Klammern) markiert anstatt als aktive Member. Also hab ich mal geschaut was mdadm mit den vorhandenen Platten anfangen kann:
Code:
sudo mdadm --assemble --scan -v -v
mdadm: looking for devices for /dev/md/0
mdadm: no RAID superblock on /dev/dm-0
mdadm: no RAID superblock on /dev/sdg
mdadm: no RAID superblock on /dev/sdf
mdadm: no RAID superblock on /dev/sde5
mdadm: no RAID superblock on /dev/sde2
mdadm: no RAID superblock on /dev/sde1
mdadm: no RAID superblock on /dev/sde
mdadm: no RAID superblock on /dev/sdd
mdadm: no RAID superblock on /dev/sdc
mdadm: no RAID superblock on /dev/sdb
mdadm: no RAID superblock on /dev/sda
mdadm: /dev/sdg1 is identified as a member of /dev/md/0, slot 5.
mdadm: /dev/sdf1 is identified as a member of /dev/md/0, slot 4.
mdadm: /dev/sdd1 is identified as a member of /dev/md/0, slot 3.
mdadm: /dev/sdc1 is identified as a member of /dev/md/0, slot 2.
mdadm: /dev/sdb1 is identified as a member of /dev/md/0, slot 1.
mdadm: /dev/sda1 is identified as a member of /dev/md/0, slot 0.
mdadm: added /dev/sdb1 to /dev/md/0 as 1 (possibly out of date)
mdadm: added /dev/sdc1 to /dev/md/0 as 2 (possibly out of date)
mdadm: added /dev/sdd1 to /dev/md/0 as 3 (possibly out of date)
mdadm: added /dev/sdf1 to /dev/md/0 as 4
mdadm: added /dev/sdg1 to /dev/md/0 as 5
mdadm: added /dev/sda1 to /dev/md/0 as 0
mdadm: /dev/md/0 assembled from 3 drives - not enough to start the array.Das ist jetzt nicht so prall und meine Frage ist, wie mache ich aus diesem Zustand wieder ein funktionierendes Raid5 mit möglichst minimalem Datenverlust?
Edit;
cat /proc/mdstat schaut jetzt natürlich so aus:
Code:
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>journalctl enthält nur Einträge nach 18.43, was der Zeitpunkt nach dem Ausfall des Raids / Systemabsturzes ist. -.-
Zuletzt bearbeitet:
