nicht angemeldet
Linux Fileserver LVM post mortem
Hello again,
ich habe vor nicht allzu langer Zeit gepostet, dass mein Linux Fileserver aus mir unerklärlichen Gründen verreckt ist. Nun ist es schon wieder passiert, daher sehe ich mich veranlasst der Sache auf den Grund zu gehen.
Diesmal bin ich etwas besser vorbereitet. Ich habe ein Backup der Daten und ich bin nicht in Panik verfallen und habe kein unsinnige Aktionen unternommen. :) Ich will systematisch versuchen den Fehler zu finden, wenn möglich die Daten wiederherzustellen und den Server wieder aufbauen. Dabei hoffe ich auf eure Hilfe, da das alles recht neu für mich ist.
Die Konfiguration des Servers:
1 CDROM Laufwerk und 3 IDE Festplatten, 2 davon sind ziemlich neue und erprobte Samsungs. Eine Platte ist eine etwas in die Jahre gekommene 120GB Maxtor.
hda - Samsung 80GB, 3 Partitionen, eine 3GB ext2 für das System (Ubuntu), eine 500 MB swap und der Rest XFS für Backups
hdb - Maxtor 120GB, eine große Partition für LVM
hdd - Samsung 250GB, eine große Partition für LVM
Die zwei LVM Partitionen habe ich zu einem volume group zusammengeschlossen und eine große logical volume darin definiert. Ich war gerade im Begriff eine große Menge an Daten auf den Server zu kopieren und gleichzeitig habe ich von einem anderen Client aus per FTP Daten von dem Server gesaugt. Dann war er plötzlich weg. Beim neu booten meldete GRUB dass er keine bootfähige Partition findet (Error 17). Ich habe mit SystemRescueCD / QTParted nachgesehen und tatsächlich, es ist keine Partition mehr active. Ausser der Backup (hda3, XFS) und swap (hda2) Partitionen ist keine Partition mehr von QTParted aus erkennbar, sie werden als unknown angezeigt und der used space ist auch unknown. So da stehe ich jetzt, was soll ich als nächstes machen?
Zur Erinerrung: Der Server ist vor einer Woche mit sehr ähnlichen Symptomen schon mal abgeraucht. Damals hatte ich noch kein LVM eingesetzt und ich habe ext3 statt XFS benutzt. Ich habe alle Festplatten mit Diagnosetools geprüft und keine Fehler feststellen können. Ich habe die System Partition mit QTParted als active markieren können und danach fuhr der Rechner wieder hoch. Die Partitionstabelle an sich schienen in Ordnung zu sein. Ich habe mit fsck die beschädigten ext3 Filesysteme wieder auf die Beine bekommen und einen Teil der Daten retten können. Der nicht rettbare Teil war allerdings nicht mehr lesbar bzw. wurde von fsck in Form von Binärdateien in lost+found abgelegt, aber damit wusste ich nichts anzufangen. Die größere Datenmenge, die ich gerade auf den Server kopiert habe, waren ironischer Weise die geretteten Daten von letzter Woche.
Ich will vor allem rausfinden was passiert ist und meine Datenwiederherstellungsskills etwas schärfen. Wer Lust hat sich daran zu beteiligen ist wilkommen Vorschläge zu unterbreiten. Ich bin zu allen Experimenten bereit und berichte gerne ausführlich die Resultate.
Gruß,
Cruz
-
Moin!
Nun ist es schon wieder passiert, daher sehe ich mich veranlasst der Sache auf den Grund zu gehen.
Ich will systematisch versuchen den Fehler zu finden, wenn möglich die Daten wiederherzustellen und den Server wieder aufbauen.
Ich will vor allem rausfinden was passiert ist und meine Datenwiederherstellungsskills etwas schärfen.
Wenn die ggf. auffindbaren Logfiles nichts ergeben, dann mußt du dich mehr oder weniger mal auf die Suche nach Hardwaredefekten machen.
Denn wenn ein Server unter Last unvermittelt und unter Datenverlust abstürzt, dann ist das nicht normal. Und auch deine Datenwiederherstellungsskills sind das allerletzte, was ich da schärfen würde, denn Datenwiederherstellung ist ganz einfach: Backup wieder einspielen. Und gleichzeitig macht es so überhaupt keinen Spaß, das regelmäßig tun zu müssen, nur weil irgendein seltsamer Faktor im Server bei hoher Last mal wieder das gesamte Dateisystem in den Abgrund gerissen hat.
Also: Hardware-Debugging-Skills schärfen.
Du solltest mit einem intensiven Test des installierten RAM beginnen. Wenn da irgendwo eine Speicherzelle defekt ist und dir Programmcode "versaut", der dann zum Absturz führt, die Speicherzelle aber nur bei hoher Speicherauslastung benutzt wird, würde das auf dein Schadensbild passen.
Schritt 2: Reproduzierbarkeit schaffen. Wenn du den Fehler mit einigermaßener Zuverlässigkeit wiederholen kannst, kannst du im dritten Schritt eingebaute Hardwarekomponenten einzeln austauschen und sehen, welche ggf. verantwortlich ist.
An einen installierten Softwarefehler glaube ich nicht so wirklich.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hallo Sven,
Wenn die ggf. auffindbaren Logfiles nichts ergeben...
Ich habe keine Ahnung wo ich was für Logfiles finden könnte, aber ich mache mich mal schlau.
Du solltest mit einem intensiven Test des installierten RAM beginnen.
OK, memtest86 läuft. Das dauert ne Weile. :)
Cruz
-
Hallo Sven,
Also: Hardware-Debugging-Skills schärfen.
memtest ist ca 16 Stunden lang mehrmals durchgelaufen, ich habe alle Festplatte mit dem jeweiligem Diagnosetool des Herstellers und dem DFT von IBM geprüft und ich habe mit PC-Check die CPU und das Mainboard getestet. Kein Test ergab irgendeinen Fehler. Es sieht so aus, als ob die Hardware in Ordnung wäre. Und jetzt?
Cruz
-
Moin!
Es sieht so aus, als ob die Hardware in Ordnung wäre. Und jetzt?
Jetzt versuchst du, den Fehler zu provozieren und beobachtest dabei Logfiles (idealerweise aus einer Shell mit ausreichend Scrollback-Puffer von einem anderen Rechner - dann bleibt dir bei einem Absturz die Textausgabe bis dahin erhalten) und Lastzustand. Wenn es dir gelingt, den Fehler gezielt wiederholbar zu machen, hilft das bei der Diagnose sicherlich (auch wenn ich noch keinen blassen Schimmer habe, was das helfen könnte). Denn ein sporadischer, nicht wiederholbarer Fehler ist kaum eingrenzbar. Also: Wiederholbar machen.
Vielleicht ist ja auch irgendeine Softwarekomponente buggy, und das Problem zeigt sich nur unter Last.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Jetzt versuchst du, den Fehler zu provozieren und beobachtest dabei Logfiles
Phew das wird mühsam. Es kann Tage dauern, bis es wieder passiert. Aber OK, eine bessere Idee habe ich auch nicht.
Welche Logs hast du denn im Sinn gehabt? Von /var/log/messages erwarte ich nicht allzu viel in diesem Zusammenhang.
-
-
-
-
Moin!
Diesmal bin ich etwas besser vorbereitet. Ich habe ein Backup der Daten und ich bin nicht in Panik verfallen
Du hast auch ein Backup der Partitionstabellen und des Bootmanagers? Falls nicht hilft dir ein einfaches, kleines Programm:
Herstellen mit: dd bs=512 count=1 if=/dev/hda of=/mnt/backupmedium/hda.mbr.yyyy_mm_dd (Das ist das Beispiel für die erste Platte am ersten IDE-Port.)
Ein Zurückspielen mit dd if=/mnt/backupmedium/hda.mbr.yyyy_mm_dd of=/dev/hda sollte dein Problem zunächst beheben. Allerdings ist damit die Ursache nicht geklärt. Im übrigen: So lange lediglich der Partitionstyp nicht mehr bekannt ist- man kann den mit parted oder fdisk einfach neu setzen.
Danach würde ich aber auf jeden Fall auch das Dateisystem gründlich prüfen.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development