9
CentOS in virtueller Maschine nach Problemen wiederhergestellt - in Log-Datei ersichtlich?
Hallo.
Wir haben ein Problem:
Ein Kunde von uns arbeitet mit unserer Datenbanksoftware.
Wir wissen, dass der Kunde vor einiger Zeit Probleme in seinem Netzwerk und mit seinen Servern hatte.
Die Datenbanksoftware liegt auf einem virtuellen CentOS-Server.
Nun ist es zu Problemen mit der Datenbank gekommen.
Wir denken, dass die Datenbank bei den Netzwerk- und Serverproblemen nicht sauber heruntergefahren wurde und sie jetzt beschädigt ist.
Wir haben nur Zugang zum virtuellen CentOS Server, aber nicht zum Server auf dem die VM's laufen.
Meine Frage:
Wenn eine virtuelle Maschine nach einem Crash aus einer Sicherung eingespielt wurde, kann man das anhand von Log-Dateien in der virtuellen Maschine (CentOS) irgendwo nachschauen?
Gruß Daniel
Wir haben ein Problem:
Ein Kunde von uns arbeitet mit unserer Datenbanksoftware.
Wir wissen, dass der Kunde vor einiger Zeit Probleme in seinem Netzwerk und mit seinen Servern hatte.
Die Datenbanksoftware liegt auf einem virtuellen CentOS-Server.
Nun ist es zu Problemen mit der Datenbank gekommen.
Wir denken, dass die Datenbank bei den Netzwerk- und Serverproblemen nicht sauber heruntergefahren wurde und sie jetzt beschädigt ist.
Wir haben nur Zugang zum virtuellen CentOS Server, aber nicht zum Server auf dem die VM's laufen.
Meine Frage:
Wenn eine virtuelle Maschine nach einem Crash aus einer Sicherung eingespielt wurde, kann man das anhand von Log-Dateien in der virtuellen Maschine (CentOS) irgendwo nachschauen?
Gruß Daniel
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 389546
Url: https://administrator.de/contentid/389546
Ausgedruckt am: 22.11.2024 um 22:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
wenn die VM aus einer Sicherung wieder eingespielt wurde, sind ja logischerweise die Folgen von nem Crash der das nötig machte nicht mehr vorhanden.
Aber deine Angaben zu den Probleme und ihrer Art etc sind leider viel zu sperrlich. So wird dir hier niemand helfen können. Außerdem ist eine "Notype"-DB auch nicht soo penibel das beim ersten Crash gleich alles hin ist. Kommt aber auch die Art der DB an. Auch dazu viel zu wenig Infos.
Gruß
bloody
wenn die VM aus einer Sicherung wieder eingespielt wurde, sind ja logischerweise die Folgen von nem Crash der das nötig machte nicht mehr vorhanden.
Aber deine Angaben zu den Probleme und ihrer Art etc sind leider viel zu sperrlich. So wird dir hier niemand helfen können. Außerdem ist eine "Notype"-DB auch nicht soo penibel das beim ersten Crash gleich alles hin ist. Kommt aber auch die Art der DB an. Auch dazu viel zu wenig Infos.
Gruß
bloody
Was fehlt Dir an Informationen?
Zur Datenbank selber kann ich nicht viel sagen.
Ich richte die CentOS Maschine ein und installiere die Datenbank.
Mit Linux habe ich erst seit März diesen Jahres intensiv zu tun. Bin also noch nicht so erfahren.
Gruß Daniel
Zur Datenbank selber kann ich nicht viel sagen.
Ich richte die CentOS Maschine ein und installiere die Datenbank.
Mit Linux habe ich erst seit März diesen Jahres intensiv zu tun. Bin also noch nicht so erfahren.
Gruß Daniel
Hallo,
wie bereits @bloodstix schon geschrieben hat, hättet ihr vorher die Logs sichern müssen. Nach der Wiederherstellung aus einem Backup sind logischerweise auch die Logs von der alten VM weg...
Um welche Datenbank handelt es sich denn?
Was heißt, ihr denkt? Was war das Problem und wie hat sich der Fehler geäußert?
Besteht das Problem nach der Wiederherstellung noch oder ist es nun weg?
Viele Grüße,
Exception
wie bereits @bloodstix schon geschrieben hat, hättet ihr vorher die Logs sichern müssen. Nach der Wiederherstellung aus einem Backup sind logischerweise auch die Logs von der alten VM weg...
Ich richte die CentOS Maschine ein und installiere die Datenbank.
Um welche Datenbank handelt es sich denn?
Nun ist es zu Problemen mit der Datenbank gekommen.
Wir denken, dass die Datenbank bei den Netzwerk- und Serverproblemen nicht sauber heruntergefahren wurde und sie jetzt beschädigt ist.
Wir denken, dass die Datenbank bei den Netzwerk- und Serverproblemen nicht sauber heruntergefahren wurde und sie jetzt beschädigt ist.
Was heißt, ihr denkt? Was war das Problem und wie hat sich der Fehler geäußert?
Besteht das Problem nach der Wiederherstellung noch oder ist es nun weg?
Viele Grüße,
Exception
Moin,
schau dir die Logfiles an. Evtl. lässt sich hier ein durch einen Zeitsprung das Wiederherstellen des Backups ableiten.
lg,
Slainte
schau dir die Logfiles an. Evtl. lässt sich hier ein durch einen Zeitsprung das Wiederherstellen des Backups ableiten.
lg,
Slainte
Zitat von @129580:
Hallo,
wie bereits @bloodstix schon geschrieben hat, hättet ihr vorher die Logs sichern müssen. Nach der Wiederherstellung aus einem Backup sind logischerweise auch die Logs von der alten VM weg...
Um welche Datenbank handelt es sich denn?
Hallo,
wie bereits @bloodstix schon geschrieben hat, hättet ihr vorher die Logs sichern müssen. Nach der Wiederherstellung aus einem Backup sind logischerweise auch die Logs von der alten VM weg...
Ich richte die CentOS Maschine ein und installiere die Datenbank.
Um welche Datenbank handelt es sich denn?
Wie gesagt, von der Datenbank selbst habe ich keine Ahnung.
Auf dieser Basis wird die Datenbank programmiert:
GT.M
Nun ist es zu Problemen mit der Datenbank gekommen.
Wir denken, dass die Datenbank bei den Netzwerk- und Serverproblemen nicht sauber heruntergefahren wurde und sie jetzt beschädigt ist.
Wir denken, dass die Datenbank bei den Netzwerk- und Serverproblemen nicht sauber heruntergefahren wurde und sie jetzt beschädigt ist.
Was heißt, ihr denkt? Was war das Problem und wie hat sich der Fehler geäußert?
Der Kunde sichert die komplette VM. Die Datenbank wird nicht extra gesichert.
Die Sicherung ist Sache des Kunden.
Besteht das Problem nach der Wiederherstellung noch oder ist es nun weg?
Es kommt zu Fehlern bei Auswertungen, wo nur noch Fehlermeldungen auftauchen, nicht mal falsche Werte.Wie schon gesagt: Im Juli gab es Probleme beim Kunden. Deswegen wurde auch die Installation eines neuen CentOS-Servers erst einmal abgesagt.
Viele Grüße,
Exception
Ich habe was im "shutdown.log" der Datenbank entdeckt:
Heruntergefahren: Sat Jun 9 00:00:02 CEST 2018
Heruntergefahren: Sun Jun 10 00:00:01 CEST 2018
Heruntergefahren: Mon Jun 11 00:00:02 CEST 2018
Heruntergefahren: Tue Jun 12 00:00:01 CEST 2018
Heruntergefahren: Wed Jun 13 00:00:01 CEST 2018
Heruntergefahren: Thu Jun 14 00:00:01 CEST 2018
Heruntergefahren: Fri Jun 15 00:00:01 CEST 2018
Heruntergefahren: Sat Jun 16 00:00:01 CEST 2018
Heruntergefahren: Heruntergefahren: Heruntergefahren: Heruntergefahren: Heruntergefahren: Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Heruntergefahren: Fri Jun 22 00:00:02 CEST 2018
Heruntergefahren: Sat Jun 23 00:00:02 CEST 2018
Heruntergefahren: Sun Jun 24 00:00:01 CEST 2018
Heruntergefahren: Mon Jun 25 00:00:01 CEST 2018
Heruntergefahren: Tue Jun 26 00:00:02 CEST 2018
Heruntergefahren: Wed Jun 27 00:00:02 CEST 2018
Das Herunterfahren um 00:00 Uhr herum entspricht dem Stoppen der Datenbank beim internen Backup.
Heruntergefahren: Sat Jun 9 00:00:02 CEST 2018
Heruntergefahren: Sun Jun 10 00:00:01 CEST 2018
Heruntergefahren: Mon Jun 11 00:00:02 CEST 2018
Heruntergefahren: Tue Jun 12 00:00:01 CEST 2018
Heruntergefahren: Wed Jun 13 00:00:01 CEST 2018
Heruntergefahren: Thu Jun 14 00:00:01 CEST 2018
Heruntergefahren: Fri Jun 15 00:00:01 CEST 2018
Heruntergefahren: Sat Jun 16 00:00:01 CEST 2018
Heruntergefahren: Heruntergefahren: Heruntergefahren: Heruntergefahren: Heruntergefahren: Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Thu Jun 21 15:46:41 CEST 2018
Heruntergefahren: Fri Jun 22 00:00:02 CEST 2018
Heruntergefahren: Sat Jun 23 00:00:02 CEST 2018
Heruntergefahren: Sun Jun 24 00:00:01 CEST 2018
Heruntergefahren: Mon Jun 25 00:00:01 CEST 2018
Heruntergefahren: Tue Jun 26 00:00:02 CEST 2018
Heruntergefahren: Wed Jun 27 00:00:02 CEST 2018
Das Herunterfahren um 00:00 Uhr herum entspricht dem Stoppen der Datenbank beim internen Backup.
Das Gleiche im "startup.log" in diesem Zeitraum:
Gestartet: Tue Jun 12 00:09:46 CEST 2018
Gestartet: Wed Jun 13 00:09:45 CEST 2018
Gestartet: Thu Jun 14 00:09:29 CEST 2018
Gestartet: Fri Jun 15 00:12:50 CEST 2018
Gestartet: Sat Jun 16 00:10:30 CEST 2018
Gestartet: Thu Jun 21 16:00:09 CEST 2018
Gestartet: Gestartet: Gestartet: Thu Jun 21 16:06:21 CEST 2018
Thu Jun 21 16:06:21 CEST 2018
Thu Jun 21 16:06:21 CEST 2018
Gestartet: Thu Jun 21 16:06:21 CEST 2018
Gestartet: Fri Jun 22 00:10:03 CEST 2018
Gestartet: Sat Jun 23 00:10:52 CEST 2018
Gestartet: Sun Jun 24 00:10:53 CEST 2018
Gestartet: Tue Jun 12 00:09:46 CEST 2018
Gestartet: Wed Jun 13 00:09:45 CEST 2018
Gestartet: Thu Jun 14 00:09:29 CEST 2018
Gestartet: Fri Jun 15 00:12:50 CEST 2018
Gestartet: Sat Jun 16 00:10:30 CEST 2018
Gestartet: Thu Jun 21 16:00:09 CEST 2018
Gestartet: Gestartet: Gestartet: Thu Jun 21 16:06:21 CEST 2018
Thu Jun 21 16:06:21 CEST 2018
Thu Jun 21 16:06:21 CEST 2018
Gestartet: Thu Jun 21 16:06:21 CEST 2018
Gestartet: Fri Jun 22 00:10:03 CEST 2018
Gestartet: Sat Jun 23 00:10:52 CEST 2018
Gestartet: Sun Jun 24 00:10:53 CEST 2018
Du solltst von einem Dienstälteren oder den Entwicklern das Handbuch zu der DB-Software anfragen. Da sollte drin stehen, wie man die Integrität überprüft und ggf. Fehler reparieren kann. Google spuckt dazu auf die Schnelle nichts aus.
Chef und Kollegin sind gerade dabei sich an die Reparatur zu machen.
Die Fehler traten laut meiner Kollegin und Chef erst Anfang September auf.
Die Ursache wird sich wohl nicht klären lassen.
Gruß Daniel
Die Fehler traten laut meiner Kollegin und Chef erst Anfang September auf.
Die Ursache wird sich wohl nicht klären lassen.
Gruß Daniel
