FreeBSD rebootet ab und an, Verdacht auf "star" -> Tape

M

Morfio

Well-Known Member
Hallo zusammen,

wir haben uns einen neuen Server geleistet, der Backups macht. Darauf installiert ist ein FreeBSD 10.1 amd64. An den Server ist ein Streamer mit Changer angeschlossen, auf den ich täglich via "star" zwei Bänder sichere.
Wir hatten bereits damals auf unseren alten Servern das Problem, dass diese ab und an rebooteten, ohne irgendwas in /var/log/messages. Das ist jetzt auch wieder das Problem.
Alle paar Tage startet der Server neu.
Ich vermute, dass es an "star" liegt. Ich denke, der schreibt irgendwelche Puffer voll, bis es ein Reboot ausgelöst wird. Ob das wirklich so ist, kann ich aber nicht sagen. Lasse ich das Band-Backup aus, startet der Server auch nicht alle paar Tage neu.
Hat jemand eine Idee, wo ich da ansetzen könnte oder kennt eine Alternative für star? Von bsdtar bin ich damals weggegangen, denn sobald ein Fehler auf dem Band war, hat bsdtar gestoppt und man kam nicht mehr an die anderen Daten.

Viele Grüße

Morfio
 
Wenn er plötzlich rebootet, läufst du wahrscheinlich in eine Panic. Ich würde daher als allererstes Kerneldumps einschalten (dumpdev="AUTO" in die rc.conf) und schauen, was sich nach einem Reboot so in /var/crash findet.
 
Habe ich jetzt in die rc.conf eingetragen. Muss ich das noch irgendwo anders zur Laufzeit aktivieren oder wird das beim Panic ausgelesen? Oder muss ich den Rechner neustarten?
 
Einen Dump des Kernelspeichers, eine Textdatei mit einer automatisiert erstellen Auswertung und dazu einige kleinere Dateien mit Metadaten. Ich würde nun ja gern ein 'ls' geben, aber ich habe gerade keine Crashdumps da. :(
 
Ich glaube in diesem Fall weiß man damit zumindest mal, dass es einen Panic gab. Und dann eben gegebenenfalls rumzeigen, damit das Problem gefixed werden kann. :)
 
Man kann die automatische Auswertung mal durchgehen. Da lässt sich auch ohne große Kernelhackerfähigkeiten zumindest nachvollziehen, welcher Prozess zur Zeit des Crashes lief und wo im Kernel er auftrat. Wenn hier z.B. star lief und das System im SCSI-Subsystem CAM abgestürzt ist, hat man den Verdacht schon mal deutlich erhärtet.
 
Danke, was passiert denn mit der Performance, wenn man das einschaltet und muß der ganze Kernel abschmieren oder reicht auch ein device aus?
 
Es hat keine Auswirkungen auf Performance oder irgendwas anderes. Wenn der Kernel eine Inkonsistenz oder ein kritisches Problem erkennt, springt er in panic(). Er tut das hauptsächlich, um den Nutzer zu schützen. Wenn der Kernel nicht mehr sauber funktioniert, kann es zu Datenverlust, falsch erzeugten Daten und vielen anderen schönen Dingen kommen. panic() gibt die Fehlermeldung aus und ruft dann doadump() auf. Die Funktion prüft, ob ein Dump-Device angegeben ist. Das ist meistens die Swap-Partition, die natürlich groß genug sein muss. 2 bis 4 Gigabyte reichen bei heutigen RAM-Mengen meist aus. Der Kernelspeicher wird dann in diese Partition geschrieben, inklusive aller eventuell enthaltener vertraulicher Daten. Danach rebootet das System.

Bei jedem Boot prüft "savecore", ob ein Dump des Kernelspeichers in dem Dump-Device liegt. Wenn ja, schreibt er ihn nach /var/crash (vorausgesetzt es ist genügend Speicherplatz vorhanden) und erstellt die automatische Auswertung. Danach wird der Dump als verarbeitet markiert und beim nächsten Boot ignoriert. Mit der automatischen Auswertung kann man sich dann die Mailingliste wenden. Für Administratoren mit vielen Systemen gibt es noch sysutils/panicmail in den Ports, was die Auswertungen automatisch ans FreeBSD Projekt schickt. Die werden nicht einzeln durchgegangen, aber können Tendenzen aufzeigen. Das sind Dinge wie: "In Release X.Y sehen wir viele Panics in einer Funktion im NFS-Code. Die müssen wir uns genauer anschauen".

Man muss dazu wissen, dass es durchaus kritische Probleme gibt, die nur alle Jubeljahre mal auftreten und sich nur finden und beheben lassen, wenn die Datenbasis groß genug ist. Wenn jemand eine Panic ein einziges Mal sieht, kann das Zufall sein. Ein Alphateilchen, was ein Bit gekippt hat. Erdstrahlen. Pech. Aber wenn zwei oder drei Nutzer die gleiche Panic sahen, ist es ein deutlicher Hinweis aus ein subtiles Problem im Code.
 
Hallo,

der Server hatte jetzt wieder eine Panic. In /var/crash ist nichts gelandet, ich konnte nur ein Foto machen.

Es könnte von hier kommen, dies ist die letzte Zeile in /var/log/messages vor dem crash:
Code: 
Jul 30 07:01:54 backy kernel: (sa0:mps1:0:3:0): 65536-byte tape record bigger than supplied buffer

Viele Grüße

Morfio
 
Hier noch das Bild
 

Anhänge

  • IMG_20150730_133549.jpg
    IMG_20150730_133549.jpg
    217,7 KB · Aufrufe: 254
Ja, sechs Stück. Zwei für das System mit UFS und gmirror, und jeweils zwei für zwei ZFS-Pools als Cache/Log.
 
OK, so mal in den Dunst hineingeraten liegt es am Trim in ZFS.
Versuchsweise würde ich mal die Sysctl-Variable vfs.zfs.trim.enabled auf 0 setzen.

Rob
 
KobTheTilla: Das ist aber wirklich lustig drauf los geraten. Bloß weil Linux derzeit Bugs im queued TRIM Code der Samsung SSDs (vllt. auch nur in Kombination mit mdraid) Bugs auslöst ist TRIM nicht plötzlich an allen Problemen beteiligt. Der ZFS TRIM Code ist von 2010 und FreeBSD unterstützt kein queued TRIM. In den 5 Jahren hat es keine gehäuften Probleme mit TRIM und ZFS geben.

Morfio: Gibt es einen Grund warum es star sein soll? Was spricht gegen das FreeBSD tar? Warum soll das Backup auf Tapes? Heutzutage sind Tapes nur noch sehr selten das optimale Medium für Backups. Natürlich ist es gut, wenn sich mit star eine Panic im SCSI CAM Code finden und beheben lässt nur als Backupstrategie würde ich dir dazu heute nicht mehr raten.
 
Crest schrieb:
Morfio: Gibt es einen Grund warum es star sein soll? Was spricht gegen das FreeBSD tar? Warum soll das Backup auf Tapes? Heutzutage sind Tapes nur noch sehr selten das optimale Medium für Backups. Natürlich ist es gut, wenn sich mit star eine Panic im SCSI CAM Code finden und beheben lässt nur als Backupstrategie würde ich dir dazu heute nicht mehr raten.
Zum Vergrößern anklicken....

Gegen das tar von FreeBSD sprach bisher immer, dass im Falle eines Fehlers auf dem Band sich FreeBSD tar weigerte, den Rest auszulesen und die restlichen Daten waren "verloren". Bei star ist das nicht der Fall und bei einem Fehler macht er einfach mit der nächsten Datei weiter.

Ich kenne leider kein besseres Backup-Verfahren als Bänder. Die Dateiserver werden bei uns gespiegelt (es gibt drei davon). Davon läuft nachts ein Backup auf unseren Backupserver, der auch von den Webservern Sicherungen macht sowie noch von ein paar anderen Servern. Die Daten werden auf fünf (täglich) sich wechselnde externe Festplatten geschrieben, die dann in der Bank lagern (täglich wird getauscht und in die Bank gebracht). Datenbankdumps werden zusätzlich auf DVDs und M-Discs gespeichert.
Für die Langzeitarchivierung nutze ich sehr gerne Bänder (LTO-5 in unserem Fall). Dafür habe ich einen Tresor, in dem ich Tagesbackups der letzten fünf Wochen sowie Montatsbackups habe. Einige Bänder werden auch zustätzlich in der Bank gelagert.

Was würdest du denn empfehlen? RDX habe ich zum Testen da, aber abgesehen von den teuren Preisen ist da immer noch eine Mechanik drin, bei der man beim Fall und bei Umwelteinflüssen doch nie sicher sein kann. Mal abgesehen davon, dass die Dinger schnarchlahm sind. Backups in die Cloud wäre noch eine Idee, bei unserer 10mbit-Standleitung mir aber zu langsam.
 
Crest schrieb:
KobTheTilla: Das ist aber wirklich lustig drauf los geraten. Bloß weil Linux derzeit Bugs im queued TRIM Code der Samsung SSDs (vllt. auch nur in Kombination mit mdraid) Bugs auslöst ist TRIM nicht plötzlich an allen Problemen beteiligt.
Zum Vergrößern anklicken....

Hast du dir den Backtrace angesehen? Das Panic findet in der Funktion trim_map_write_start() statt. Ich wollte bloß diese Fehlerquelle ausschließen, indem Trim einfach mal deaktiviert wird. Ich habe mich in keiner Weise auf den Linux-Queued-Trim-Bug bezogen.

Wie gesagt empfehle ich dem OP Trim zu deaktivieren um das Problem einzugrenzen.

Rob
 
Mich erstaunt, daß er 64K nicht in den Buffer kriegt.
Was genau machst Du da womit und sind die Bänder groß genug und wann passiert das?

Mich wundert auch, warum Du da was mit star machst, anstatt einfach einen Amanda-Server aufzusetzen, der deine Archive pflegt und säubert?
 
Mich erstaunt, daß er 64K nicht in den Buffer kriegt.
Was genau machst Du da womit und sind die Bänder groß genug und wann passiert das?
Zum Vergrößern anklicken....
Die Bänder sind groß genug (1,5TB netto ohne Verschlüsselung bei 1,3TB Daten, die drauf sollen).
Das Laufwerk scheint aber Probleme zu haben, wie ich jetzt sah. Könnte ein Hardwarefehler sein.

Mich wundert auch, warum Du da was mit star machst, anstatt einfach einen Amanda-Server aufzusetzen, der deine Archive pflegt und säubert?
Zum Vergrößern anklicken....
Hatte ich mich noch nie mit beschäftigt. Das ganze Backup ist von mir von vorn bis hinten durchgescriptet, da bot sich das an, weil es schön einfach ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben