Danke nochmal,
ja ein Raid Defekt war vor 3 Monaten. Da vielen mir 2 Disks von 4
gleichzeitig aus. Eine der beiden konnte ich mit dd auf eine neue
kopieren und das Raid neu zusammenfügen.
Allerdings funktionierte das System dann noch 2 Monate. Einen
Filesystem Check machte ich leider nicht.
Liegt da mein Fehler?
Gruß
Alexander.
Am 2017-01-20 um 18:49 schrieb Matthias Schweizer:
Hi,
Dateisystemfehler entstehen meist, wenn das darunterliegende Medium
defekte aufweist. So gesehen, nein Du hast Dich nicht falsch
ausgedrückt, du beschränkst Dich nur auf die Auswirkung und nicht auf
die Ursache. Diese liegt mit sehr hoher Warscheinlichkeit in einem
defekten Raidverbund der zu noch höherer Warscheinlickeit durch defekte
Platten verursacht wird.
Das simple korrigieren von Dateisystemfehlern wird niemals die Ursache
beseitigen können. Du musst Dich also von unten nach oben arbeiten.
- Fehlerspeicher von Platten prüfen. ( Ist nicht immer aussagekräftig
wenn nichts drin steht heisst das nichts! )
- Raidverbund prüfen.
- Jetzt erst das Dateisystem
Cheers
Hias
On 20.01.2017 18:41, Burner wrote:
Danke für die schnellen Antworten.
Da hab ich mich wohl falsch ausgedrückt. Nicht das Raid ist defekt
sondern das Filesystem ext4 auf dem Raid hat Fehler.
Als ich vor 3 Wochen mit sudo mount /dev/md0 /mnt -r die Partition
lesend eingebunden habe waren die Dateien noch alle vorhanden. Nur
konnte ich die Partition nicht automatisch durch die fstab beim
Systemstart mounten da ubuntu meckerte dass noch Fehler bestehen.
Daher versuche ich jetzt schon seit längerem mit fsck.ext4 -f -y die
Fehler aus dem ext4 System zu bekommen. Auch hab ich schon sudo e2fsck
-f -y /dev/md0 versucht. Alle Durchgänge dauern Tage. Na ja bei 6TB
ist das ja auch verständlich.
Allerdings sind beim letzten mal mounten einige 100GB Dateien
verschwunden. Mit welchem Programm soll ich da rangehen? testdisk ?
Gruß
Alexander.
Am 2017-01-20 um 18:11 schrieb Matthias Schweizer:
Hallo Alexander,
ich gehe jetzt mal von einem Softwareraid aus da Du md0 geschrieben hast
.....
Die Vermutung liegt nahe, dass eine Platte ausgefallen ist und eine
weitere bereits Fehler aufweist.
Raidverbund prüfen:
cat /proc/mdstat
hier sollten alle Partitionen mit U gekennzeichnet sein ( Up2Date )
oder
mdadm –detail /dev/md0
hier müssen alle Platten in "active sync" stehen
ist das nicht der Fall gehts schon los....
smartctl -a /dev/sda ( Fehlerspiecher der Platte sda auslesen )
für weiter Platten /dev/sdb, /dev/sdc usw.
Sind hier Fheler vorhanden, platten tauschen und Raidverbund neu
aufbauen.
vorher die defekten Platten als faulty markieren ( man mdadm )
mdadm -f /dev/md0 /dev/sdb1
und Platte entfernen
mdadm -r /dev/md0 /dev/sdb1
Partitionstabelle Dumpen ( sfdisk -d /dev/sda > sda.sfdisk )
auf z.B der neuen Platte, hier sdb, wieder einlesen ( sfdisk /dev/sdb <
sda.sfdisk )
usw. usf.
Raidverbund wieder aufbauen.... Viel Zeit mitbringen ;)
mdadm -a /dev/md0 /dev/sdb1
Alles nur wenn sdb die kaputte Platte ist!!!!!!!!
Wenn was schief geht. Ich wars nicht. Das ist nur eine Hilfestellung
keine Patentlösung. Für evtl. Schäden und Datenverlust übernehme ich
keinerlei Verantwortung!
cheers
Hias
On 20.01.2017 17:38, Burner wrote:
Hallo,
mein Name ist Alexander Burner. Mein privater Server (Ubuntu 16.04
LTS) hat ein Raid5 auf dem eine 6TB großen ext4 Partition ist.
Vor 1 Monat meldete sich beim Hochfahren das System und verweigerte
das Einbinden der Partition.
Ich versuche seither mit fsck.ext4 -f -y /dev/md0 den Fehler zu
beheben. Mir kommt jedoch vor als werden es immer mehr Inodes die
fehlerhaft bzw doppelt belegt sind.
Gibt es noch bessere Werkzeuge als fsck ?
Als ich das letzte mal die Partition "nur lesend" gemountet habe
fehlten etliche Dateien. Mit df wird jedoch so ungefähr der ganze
verbrauchte Speicherplatz mit den nicht angezeigten bzw verschwundenen
Dateien angezeigt.
Gruß
Alexander.
_______________________________________________
lug-ts mailing list
[email protected]
http://www.lug-ts.de/mailman/listinfo/lug-ts
_______________________________________________
lug-ts mailing list
[email protected]
http://www.lug-ts.de/mailman/listinfo/lug-ts
_______________________________________________
lug-ts mailing list
[email protected]
http://www.lug-ts.de/mailman/listinfo/lug-ts
_______________________________________________
lug-ts mailing list
[email protected]
http://www.lug-ts.de/mailman/listinfo/lug-ts
_______________________________________________
lug-ts mailing list
[email protected]
http://www.lug-ts.de/mailman/listinfo/lug-ts
