Serverabsturz nach NC Umzug zu Hetzner

Hallo zusammen,

ich habe seit letzter Woche einen Server bei Hetner angemietet. Samstag unsere Nextcloud Intanz dann umgezogen. Lief alles perfekt am Samstag und Sonntag dann. Server ist heute Nacht dann beim Backup um 2:30 das erste mal ausgestiegen. Heute morgen dann auch zweimal innerhalb zwei Stunden, Hetzner hat die Festplatten in einen neuen Server eingebaut, aber immer noch die gleichen Probleme. Server stürzt auch ab wenn der Webserver offline ist undk eine Anfragen annimmt. Sehr komisch. JEmand eine Idee welche Logs hilfreich sind?

Hallo,

ich hatte kürzlich auch Probleme mit einem Server. Beim genauen Hinsehen stellte sich heraus dass das Raid „degradet“ war.

Deshalb würde ich erst mal danach schauen und dann die Festplatten mit den Smartmontools auslesen lassen.

Eine weitere - mögliche - Fehlerquelle ist der Arbeitsspeicher. Den würde ich auch mal untersuchen (lassen?).

Gruß

Alois

Ja wir sind gerade dran. Mit dem Support zusammen habenw ir rausgefunden, dass der KErnel wahrscheinlich zu alt ist für den RAM, Jetzt ziehen wir Ubuntu auf 20.04 hoch…

Hallo,

bei Hetzner kann man seinen Server im Rescue booten lassen und so den Zustand besser untersuchen.

VG Andre

1 „Gefällt mir“

Bisher habe ich in der kernel log folgendes drin gehabt:

Jan 18 08:14:17 kernel: [ 6.256557] EDAC amd64: Node 0: DRAM ECC enabled.
Jan 18 08:14:17 kernel: [ 6.256559] EDAC amd64: F17h detected (node 0).
Jan 18 08:14:17 kernel: [ 6.256563] EDAC amd64: Error: F0 not found, device 0x1460 (broken BIOS?)

So wir haben das Betreibssystem mit Kernel auf den aktuellen Stand gebracht. Diemal ohne diesen Fehler gebootet.

an 18 13:36:10 [ 5.016942] EDAC amd64: Node 0: DRAM ECC enabled.
Jan 18 13:36:10 [ 5.016943] EDAC amd64: F17h_M70h detected (node 0).
Jan 18 13:36:10 [ 5.016990] EDAC MC: UMC0 chip selects:
Jan 18 13:36:10 [ 5.016991] EDAC amd64: MC: 0: 16384MB 1: 16384MB
Jan 18 13:36:10 [ 5.016992] EDAC amd64: MC: 2: 16384MB 3: 16384MB
Jan 18 13:36:10 [ 5.016994] EDAC MC: UMC1 chip selects:
Jan 18 13:36:10 [ 5.016995] EDAC amd64: MC: 0: 16384MB 1: 16384MB
Jan 18 13:36:10 [ 5.016995] EDAC amd64: MC: 2: 16384MB 3: 16384MB
Jan 18 13:36:10 [ 5.016996] EDAC amd64: using x16 syndromes.
Jan 18 13:36:10 [ 5.016996] EDAC amd64: MCT channel count: 2

System lief, ich hab Backup Prozess angestoßen (pigz packt da einiges zusammen) und kurz darauf ist der Server wieder offline. Ich bekomme ich auch nicht über das Hetner WEbend neu gestartet, muss jedes mal mit dem Support schreiben…

Hatte ich heute morgen schon, der Support ist echt mega bemüht. Aber trotzdem kacke, Server läuft am Wochenende stabil durch und Sonntag auf Montag nacht verabschidet sich das Ganze…

Also so was hatte ich noch nicht, Kernel ist nun der aktuellste 5.8.0-38 auf einem Ubuntu 20.04. Sobald ich beispielsweise Backup via Ples starte, ist der Server nach ein paar Minuten komplett weg, nicht mehr anpingbar. Logs habe ich soweit gelesen, sehe aber nicht wirklich was außer das DRAM ECC, das aber angeblich mit dem neuen Kernel behoben sien sollte.

Ist wirklichg erade echt bescheiden. Bina m überlegen ob ich nochmal komplett neu aufsetze und eventuell auf Intel zurückwitche.

Hallo,

irgendwie erinnert mich das an das Backup „Mondo“, welches wir in früheren Versionen von linuxmuster.net verwendet haben. Dieses Backup fährt alle Dienste herunter und nach Abschluss wieder hoch.

Vielleicht ist es ja das?

Gruß

Alois

nein, es bricht alles ab. Kein Ping, kein SSH, kein REmoterestart, sogar die KVM heute morgen war tot.

Was ergibt ein Speichertest?

Gruß

Alois

Wie führe ich den am besten durch per ssh?

Hallo,

das wird man möglicherweise vor Ort anstoßen müssen. Bei Linux nennt sich das memtest. Manche Computer bieten das auch vor dem Sysemstart an.

Gruß

Alois

Ich habe jetzt zum zweiten mal das System gewechselt, nur Festplatten wurden mitgenommen. Bin mal gespannt. Sehr unwahrscheinlich dass ich dreimal ein System bekomme mit fhelerhaftem Speichher. Der komplette Hardware Check dauert 10 bis 14h, das is t ne lange Zeit dafür dass ich gerne morgen wieder online sein möchte…

Hallo,

also wenn der Server abschmiert und dann werden die Platten in einen
neuen Server gesteckt und das Problem bleibt … dann sind es die
Platten… so sehe ich das.
Also: neue Platten rein. (ich weiß: man muss komplett neu aufspielen …)

LG

Holger

Hallo,

das klingt nicht gut.
Aber ich vermute, dass der ältere Kernel nicht das Problem sein kann.
Verwendest Du schon das Programm

edac-util ?

Damit habe ich schon zweimal erfolgreich defekte ECC-RAM-Riegel diagnostiziert (ausgetauscht, Server lief wieder zuverlässig. Vorherige Faheler waren nur sporadisch, führten aber auch zum Totalabsturz).

Zweite Idee:
Du mountest per ntfs ein Laufwerk auf einem anderen Server (oder Deinem Rechner) und schreibst sämtliche Logdaten während des backups DARAUF.
Die letzten Meldungen, bevor Dein System abraucht, könnten Aufschluss über die Ursache geben, vielleicht ein Designfehler im Backup-Programm. Vielleicht verlierst Du wegen buffering ein paar Daten, aber ansonsten schreibst Du ja quasi direkt das Log auf die empfangende Serverplatte.

Viele Glück
Christoph

Platten finde ich shcon ungewöhnlich, vor allem im Raid verbung. RAM; CPU; sogar das Mainboard hätte ich in Verdacht, aber Festplatten nicht wirklich. Jetzt schauen wir mal was rauskommt, habe gerade das Backup angestoßen und Server packt mal alles mit pigz zusammen. Bekomme schon nen halben Herzinfakt wenn htop bei ssh für eine Sekunde lagt.

Hallo,

das hätte ich bis vor kurzem auch gesagt. Trotzdem waren es die Festplatten (genau genommen das Raid).

Gruß

Alois

Jetzt warten wir mal ab. Das Backup lokal hat schon mal geklappt, jetzt noch ein Durchlauf mit rausschieben via ftp. Dann gehts auch schneller mit Platten tauschen, falls es wirklich notwendig wird. Und falls dann alles klappt, machen wir die Cloud wieder auf… Ansonsten erstmal Danke an Christoph für den Tipp, das probiere ich gerne aus wenn es zu weiteren Freeze kommen sollte.
Aber das wird noch ne auregende Woche, muss glabu ich jeden Morgen mal gegen 6 schauen ob noch alles läuft. Glücklicherweise läuft unser BBB stabil.

Das klingt alles andere als gut, richtiger Schockmoment wenn der Server einfriert und absolut nicht geht und viele SuS darauf angewiesen sind.
Kernel ist jetzt auf jeden Fall uptoDate, an dem kannes jetzt ja nich mehr liegen.

gerade installiert, mc0: 0 uncorreted; 0 correctecd; no Errors to REport;
Hoffen wir mal dass da so bleibt. Kann das Programm auch dauerhaft überwachen oder wie bist du den RAM Fehlern auf die Schliche gekommen?

So Backup auf em FTP ist auch gemacht, dann aktivieren wir mal wieder die Cloud. Bin mal gepsannt ob es jetzt läuft.

RAID ist kein Garant fuer keine Ausfaelle, wir haben mal direkt auf der Platte Sektoren kaputtgeschrieben, das hat das System ueberhaupt nicht mitbekommen.
Ich hab das oben aber auch nicht alles gelesen, die Platten wuerde ich aber nicht gleich ausschliessen. Im Extremfall sind die die letzten 6 Jahre 24/7 unter Vollast gelaufen.

Hast Du Dir mal mit mdadm den Status der Platte angesehen?
Man sieht uebrigens damit auch, wieso der Hetznerserver die ersten paar Stunden so kreuzlahm ist, er baut erstmal das Array auf.

root@bbb-shit:~# mdadm --detail /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Sun Apr 12 11:20:59 2020
     Raid Level : raid1
     Array Size : 1936078912 (1846.39 GiB 1982.54 GB)
  Used Dev Size : 1936078912 (1846.39 GiB 1982.54 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Mon Jan 18 19:29:50 2021
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : rescue:2
           UUID : 888c95a6:dce2fb27:287a2556:60076020
         Events : 50414

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3