Server stribt um Mitternacht

[belzebob]

Hallo,

habe seit 4 Tagen das Problem das mein Server kurz nach Mitternacht "stirbt". Ab da können keine Dateien mehr geschrieben werden, es kommt immer die Meldung: "read only filesystem". Im Syslog steht immer etwas anderes, mal hat gerade jemand versucht Mails abzuholen, mal sollte gerade eine durchgestellt werden, alles Sachen die Nachts halt passieren. crontab -l bringt keinen Cornjob der um Mitternacht läuft, ich konnte aber noch nicht herausfinden wie ich mir die crontabs aller User auflisten lassen kann.

Wäre super wenn mir jemand einen Tipp hätte nach was ich suchen könnte, bzw. vielleicht sogar direkt bei der Problemlösung helfen könnte.

Grüße

Belzebob

[daemotron]

"read only filesystem" deutet darauf hin, dass der Kernel das betroffene Dateisystem wegen Zugriffsfehlern als read-only neu eingehängt hat. Ist immer dasselbe Dateisystembetroffen, deutet das darauf hin, dass entweder das Dateisystem einen Schuss weg hat (mal mit fsck prüfen) oder sogar die Platte in dem Bereich defekte Sektoren hat (smartmontools mal bemühen oder mit fsck nach defekten Blöcken suchen). Wenn nur das Dateisystem betroffen ist, kommen mehrere Ursachen in Betracht. Das Dateisystem könnte vollgelaufen sein, fehlerhaft gemounted worden o. ä. Gibt es defekte Blöcke, deutet das aber auf eine sterbende Platte hin. Wenn die smartmontools Fehler melden, solltest Du den Hoster um Austausch der Platte bitten.

[belzebob]

Vielen dank!
Komisch ist, dass das immer um kurz nach 12 Uhr passiert.

[belzebob]

Habe jetzt mit dd die sda auf die sdb "kopiert". Die sdb wurde jetzt zur sda, leider tritt der Fehler immer noch auf. Habe ich jetzt den "Fehler" mit dd kopiert, oder liegt es wohl doch an was anderem? Jemand noch nen Tipp für mich?

Eine Zwischenlösung wäre es via cron um 5 Uhr morgens den Server neu zu starten, das würde mir wieder mehr Schlaf gönnen. Leider bewirkt auf meinem Debian ein cron "00 05 * * * /sbin/shutdown -r now" gar nichts. Habe es auch schon mittels externem Script versucht das dann via cron aufgerufen wird, leider geht das auch nicht.

[Joe User]

Neues Filesystem (XFS) anlegen und nur die Daten kopieren, danach ummounten und ich wette der Fehler ist weg...

[belzebob]

Hmmm, ich tu mich da immer schwer bei Servern auf die ich keinen Physischen Zugriff habe aber wäre das dann so der richtige weg:

- Anlegen eines neuen root-Filesystems auf sdb mit Dateisystem XFS (sdb1)
- Daten mit cp von sda2 (aktuelles root) auf sdb1
- LILO umkonfigurieren, dass beim Neustart root von sdb1 verwendet wird.

Damit ich aber wieder alles auf einer HD habe würde ich dann:

- sda2 auf XFS umformatieren
- mittels cp Daten von sdb1 auf sda2 kopieren
- LILO wieder zurück stricken sda2 = root

Passt das so, oder ginge das noch schneller/einfacher?

Grüße

[belzebob]

Probiere es jetzt mal mit: "tar -cpf - . | ( cd /mnt/NEW && tar xpvf - )", dann sollten die /dev ja mit kopiert werden. Bin mal gespannt ob ich bei /mnt/NEW in einer Endlosschleife lande und ein schwarzes Loch erzeuge.

[Joe User]

Neues Filesystem (XFS) anlegen und nur die Daten kopieren, danach ummounten und ich wette der Fehler ist weg..

Was verleitet Dich zu dieser Annahme?

Wie hoch ist die Wahrscheinlichkeit, dass zwei unterschiedlich belastete HDDs zur gleichen Zeit den gleichen Defekt erleiden? Ein mit dd transferiertes FS hingegen behält seine Fehler...

[oxygen]

Allerdings werden dann unter Umständen einige Dateien nicht kopiert werden. Auf jedenfall die Ausgabe von cp oder rsync sehr genau beobachten und wenn nötig aus Backup wiederherstellen. Oder wenn möglich das entsprechende Paket neuinstallieren.