Fast exakt, aber genau da liegt Dein Problem. Never ever füge eine mit einem dd erzeugte Disk zu einem bestehenden Raid hinzu ohne neu Aufzusyncen. Ergo bringt der dd nichts, denn die Platte muss sowieso neu gebuilded werden. Mit dem dd hast Du Dir die Fehler 1:1 auf die neue Platte kopiert ohne dass das Softraid davon etwas mitbekommen hat. Nun machen sich die Fehler bemerkbar. Du muss immer die zu tauschende Platte als faulty makieren und dann, wie eingangs erwähnt, aus dem Verbund auslösen ( remove -r ) danach die neue Platte wieder adden und das SoftRaid beginnt mit syncronisation.
mdadm -a /dev/md0 /dev/sdb1 Was Du nun brauchst ist ein gutes Backup.... Die sauberste Lösung wäre einen neuen Verbund "From Scratch" zu erzeugen und dann das Backup zurückkopieren. Am Besten filebasiert. mdadm --create /dev/md0 --level=5 --raid-disks=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd ( die Einzelpartitionen beim Raid sind überflüssig..... aber nur wenn Du ein neues baust. Danach würde ich Dir empfehlen eine VolumeGruppe ins Rd zu legen und dort stellvertretend für Deine Partitionen logische Volumes zu erzeugen. Aber das ist ein anderes Thema .... ) Alles andere wäre aktuell bei Dir "Leichenwaschung" um die schleichende Verwesung Deiner Daten zu verzögern..... Komm morgen auf den Stammtisch im Wochinger in Traunstein ab 1700 da stehen wir Dir alle mit Tips und Tricks aber zunächst mal mit Bier zur Seite. Den Frust zu ertränken hilft erstmal. Zum anderen ists immer lustig und interessant. Da lernst auch das CoreTeam also die (fast) ImmerDa Jungs kennen. Freut uns alle wenn Du kommst :o) Cheers Hias On 20.01.2017 19:46, Burner wrote: > 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 _______________________________________________ lug-ts mailing list [email protected] http://www.lug-ts.de/mailman/listinfo/lug-ts
