Fileserver LVM post mortem

[Cruz]

Hello!

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

 

[Vegeta]

Grub scheint nur Probleme mit dem Dateisystem auf Deiner Partion zu haben.
http://www.gentoo.org/doc/de/grub-error-guide.xml

Vegeta

 

[Goodspeed]

Deine Daten auf hdb und hdd sind sicherlich nicht betroffen, von daher würde ich mein Hauptaugenmerk auf die root-Partition hda1 legen ...
Kannst Du per Live-CD auf die noch zugreifen?
Was sagt denn

fdisk -l /dev/hda

?

Der Rechner an sich, hat keine Probleme mit großen Festplatten (BIOS, Mainboard)?
Wenn Dir die Systemplatte schonmal verreckt ist, würde ich mal einen Hardwarecheck (Link) durchführen ...

 

[Cruz]

Hallo Goodpseed,

ich habe memtest86 über 16 Stunden lang laufen lassen. Ich habe alle Festplatten mit dem Diagnosetool des jeweiligen Herstellers und dem von dir empfohlenen DFT von IBM geprüft. Ich habe auch noch PC-Check benutzt, um die CPU und die Mainboard Funktionen zu testen. Es sind keine Hardwarefehler festzustellen.

Hier ist der Output von fdisk -l

Disk /dev/hda: 80.0 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 392 3148708+ 83 Linux
/dev/hda2 393 456 514080 82 Linux swap / Solaris
/dev/hda3 457 9733 74517502+ 83 Linux

Disk /dev/hdb: 122.9 GB, 122942324736 bytes
255 heads, 63 sectors/track, 14946 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 1 14946 120053713+ 8e Linux LVM

Disk /dev/hdd: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdd1 1 30401 244196001 8e Linux LVM


Das einzige, was ich daraus erkennen kann ist, dass die Partitionen von /dev/hda1 und /dev/hda3 als "Linux" angezeigt werden. Dabei sollten sie ext2 und xfs sein. Die anderen Partitionen sind alle richtig.

Hier ist auch noch der Output von parted /dev/hda print:


Disk geometry for /dev/hda: 0kB - 80GB
Disk label type: msdos
Number Start End Size Type File system Flags
1 32kB 3224MB 3224MB primary
2 3224MB 3751MB 526MB primary linux-swap
3 3751MB 80GB 76GB primary xfs


Information: Don't forget to update /etc/fstab, if necessary.


Hier wird die xfs Partition auf hda richtig angezeigt.

Ich habe auch noch versucht den logical volume zu mounten, der sich über hdb und hdd erstreckt, es funktioniert nicht.

Ich weiss nicht was ich als nächstes machen soll. Ich könnte jetzt versuchen mit den fsck tools die Filesysteme wiederherzustellen, aber eigentlich möchte ich wissen was passiert ist. Hast du noch einen Tipp was ich mir noch anschauen kann? Gibt es irgendwelche logs, die sinnvolle Informationen beinhalten können?

Danke
Cruz

 

[Goodspeed]

fdisk kennt keine Filesysteme, von daher ist die Ausgabe schon o.k.
Kannst Du /dev/hda1 per Live-CD mounten?

Was ist das für ein Mainboard-Chipsatz?
Die IDE-Controller sind auf dem Board oder PCI-Karten?

Um von einem externen System (z.B. Live-CD) an Dein LVM zu kommen, solltest Du Dir mal die Tools pvscan/vgscan/lvscan ansehen ... denn in der Regel weiß das neue System noch nichts von Deiner LVM-Konfiguration ..

 

[Cruz]

Kannst Du /dev/hda1 per Live-CD mounten?

Nope. "wrong master superblock magic..." bla bla.

Was ist das für ein Mainboard-Chipsatz?

North Bridge: VIA KT266A
South Bridge: VIA VT8233

Die IDE-Controller sind auf dem Board oder PCI-Karten?

Sind sind onboard. Der Setup lief ein paar Monate lang geschmeidig. Ich glaube nicht, dass das Problem eine grundsätzliche Unverträglichkeit ist. Irgendwann ist es plötzlich passiert. Und nachdem ich alles neu formatiert und installiert habe und gerade im Begriff war die Daten wieder zurückzukopieren, ist es sofort wieder passiert. Ich wette es würde wieder passieren, wenn ich es erneut neu aufsetze und unter Last setze. Also wenn du auch keine Spuren mehr weisst, nach denen ich im Wrack suchen könnte, dann könnte ich versuchen den Fehler erneut zu provozieren und dabei dies und jenes auf einem anderem Client mitloggen...ich weiss bloss nicht so recht was.

Um von einem externen System (z.B. Live-CD) an Dein LVM zu kommen, solltest Du Dir mal die Tools pvscan/vgscan/lvscan ansehen ... denn in der Regel weiß das neue System noch nichts von Deiner LVM-Konfiguration ..

Ja danke da habe ich mich schon schlau gemacht. Ich weiss allerdings nicht, wo die LVM Information gespeichert wird. Es hat mich schon gewundert als ich mein erstes LVM probeweise unter einer Live CD eingerichtet habe und sie war immer noch da, nachdem ich von einer _anderen_ LiveCD neu gebootet hab.

 

[Goodspeed]

Nope. "wrong master superblock magic..." bla bla.

Schlecht. Da wird es wohl auf fsck hinauslaufen ...

North Bridge: VIA KT266A
South Bridge: VIA VT8233

Hmm ... mit dem KT133A gab's mal Probleme bei Last, aber hier ... ??

Also wenn du auch keine Spuren mehr weisst, nach denen ich im Wrack suchen könnte, dann könnte ich versuchen den Fehler erneut zu provozieren und dabei dies und jenes auf einem anderem Client mitloggen...ich weiss bloss nicht so recht was.

Naja, vielleicht haste auch Glück und nach dem fsck ist das syslog noch vorhanden ... dann kannste ja erstmal da schauen, bevor Du von vorn anfängst ...

Ja danke da habe ich mich schon schlau gemacht. Ich weiss allerdings nicht, wo die LVM Information gespeichert wird. Es hat mich schon gewundert als ich mein erstes LVM probeweise unter einer Live CD eingerichtet habe und sie war immer noch da, nachdem ich von einer _anderen_ LiveCD neu gebootet hab.

Hast Du mal die o.g. LVM-scan-tools genutzt?
Normalerweise werden die auch durch das Init-Script gerufen, aber vielleicht muss man denen bei Dir ja etwas auf die Sprünge helfen.

 

[Cruz]

Hast Du mal die o.g. LVM-scan-tools genutzt?
Normalerweise werden die auch durch das Init-Script gerufen, aber vielleicht muss man denen bei Dir ja etwas auf die Sprünge helfen.

Die scan Tools funktionieren, aber die tun nicht besonders viel. Um eine lv zu mounten muss man beim hochfahren die volume groups mit vgchange -ay aktivieren.

Ich bin mit fsck vorgegangen und es sieht gar nicht gut aus. Interessant ist schon mal, dass in allen beschädigten Partitionen die superblocks verloren waren.

/dev/hda1 war leider so gut wie gar nicht zu retten. e2fsck wollte beim besten willen nicht ansprigen, weil er eben den superblock vermisst hat. Ich habe natürlich probiert mit e2fsck -b xxxx /dev/hda1 manuell mögliche Adressen anzugeben, aber es war alles erfolglos. Letztendlich habe ich mit mkfs -S die superblocks neu erstellt. Danach lieft fsck eine Weile und brach dann mit einem segmentation fault ab. Vom Filesystem habe ich kaum etwas zurückbekommen, im Grunde nur die home Verzeichnisse. Von logs leider keine Spur.

Die große XFS logical volume war ähnlich stark beschädigt, auch hier waren die superblocks nicht mehr in Ordnung. Aber xfs_repair ist schlauer, als e2fsck und hat selbständig das Filesystem nach einem backup superblock gescannt. Von denen waren auch einer kaputt, aber bei der dritten Fundstelle war er endlich zufrieden und hat eine Reperatur versucht. Alles in allem ist die XFS Partition wieder auf die Beine gekommen, etwa die Hälfte der Daten befindet sich jetzt im lost+found in zermatschter Form.

Ich habe viel im Internet gesucht was zu tun ist, wenn der superblock weg ist. Ein wirkliches Rezept habe ich dafür nicht gefunden. Verursacht wurde es bei den meisten Opfern durch einen Stromausfall, aber das war bei mir garantiert nicht der Fall.

So, jetzt bin ich kaum schlauer als vorher. Ich habe leider immer noch nicht die leisteste Vermutung was den Verlust der superblocks verursacht. Was soll ich als nächstes machen? Soll ich den Server wieder neu aufsetzen und von einem client aus das syslog offen halten, während ich den Server belaste? Oder soll sukzessive eine Platte aus der Konfiguration rausnehmen und schauen, ob die Kiste dann stabil wird?

 

[Goodspeed]

Das klingt ja richtig böse ...

Danach lieft fsck eine Weile und brach dann mit einem segmentation fault ab.

Sowas kenn ich eigentlich nur aus 3 Szenarien:
1. Kernel kaputt
2. falsche libc6
3. Hardwarefehler (insbesonder Speicher)

1+2 kann man sicherlich ausschließen, wenn Du die normalen Ubuntu-Pakete + (falls es sowas gibt) Sicherheitsupdates hast.
Bleibt 3 ... Memtest ist nicht 100%-ig.
Wieviel und was für welchen Speicher haste in der Kiste?
Eventuell mal ausbauen oder tauschen (insbesondere NoName oder Billig-Speicher)

Für die Zukunft ... hmmm ... Du könntest versuchen per Script beim herunterfahren "/var/log/" auf ein NFS-Share oder ähnliches zu speichern ...
Und mal nach einem BIOS-Update schauen und da im Changelog mal schauen, ob bzgl. des PCI-Buses oder ähnliches was korrigiert wurde ...

 

[Cruz]

3. Hardwarefehler (insbesonder Speicher)

Ich hatte gehofft, dass es nicht dazu kommt, denn es ist ein endloses Gefrickel die Hardware Stück für Stück zu debuggen. Aber gut. Ich habe 750 MB billigen noname RAM in der Kiste, der seit 4 Jahren treu seinen Dienst tut. Eine der Halteklammern am RAM Sockel ist gebrochen, aber das dürfte eigentlich keine Probleme machen. Der Riegel sitzt richtig im Sockel und wenn da was ist dann geht es entweder ganz oder gar nicht.

Ich habe jetzt erstmal den ganzen RAM bis auf einen Riegel rausgerissen und auch eine der Festplatten entfernt. Mal sehen wie gut sich der Rechner in dieser Minimalkonfiguration macht. Wenn er einen 250GB grossen rsync überlebt, dann stecke ich den restlichen RAM wieder zurück. Ich bin übrigens überrascht wie flüssig Ubuntu mit 250 MB läuft.

Das wird jetzt Tage dauern, bis ich mit dem Hardwaretest durch bin. Ich poste dann wie es ausgegangen ist. Vielen Dank für die Hilfe soweit.

Cruz

 

[Cruz]

Hallo,

wollte nur meinen Abschlussbericht loswerden. Habe nach tagelangem herumbasteln und Stresstests festgestellt, dass der Rechner stabil läuft, wenn ich die 120GB Maxtor Platte rausnehme. Am RAM scheint es nicht zu liegen. Leider weiss ich nun immer noch nicht genau, woran es gelegen hat, aber wenigstens läuft mein Server wieder.

Gruß,
Cruz