Hi,
mein Server wollte vor 2-3 Tagen nicht hochfahren.
Da waren Probleme mit dem SATA Kabel.
Musste Ihn dann mit Gewalt ausschalten. Stecker ziehen.
Beim Hochfahren dann keine Platte gefunden. Also nochmal aus und die Kabel ab und wieder dran.
Dann lief er in einen -press ctrl-d or give root passwd ..... etc -
Habe dann root passwort eingegeben.
konnte kein auto fsck ausführen.
Also habe ich das manuell gemacht.
Er hat auch einiges bemängelt und ich habe des öfteren Y gedrückt.
Ihr kennt die Prozedur bestimmt.
Heute dann wollte ich eine wichtige Datei öffnen und die war KAPUTT
Ich habe zwar ne Sicherungskopie, aber die ist 4 Monate alt.
Zum Glück macht mein System im Samba recycler Sicherungskopien beim bearbeiten.
Konnte die Datei von vor 3 Tagen dort finden.
Aber welche Dateien hat er noch zerbröselt ?
Wie kann ich denn sehen, welche Dateien er "Repariert" hat bzw in meinem Fall kaputt repariert hat.
Gibt es da ne LOG Datei ?
In /var/log/fsck ist eine Datei, in der aber nix gescheites drinn steht.
Fsck - gibt es ne LOG Datei ?
-
- Beiträge: 3800
- Registriert: 26.02.2009 14:35:56
Re: Fsck - gibt es ne LOG Datei ?
Server heißt für mich - ich habe immer ein aktuelles Backup - Platte kann ja auch total abrauchen, dann ist alles auf der "ewigen Weide". Besonders die Nutzerdaten sollten immer aktuell gesichert sein. Mach erst mal ein smartctl --all und schau nach - tippe auf Plattenfehler.
Re: Fsck - gibt es ne LOG Datei ?
Wurde die Datei denn seit den 4 Monaten nicht mehr verändert?
Dann kann der Vorfall vor 2-3 Tagen ja (fast?) nicht schuld daran sein und ich würde vermuten, dass es davor schon Probleme mit der Festplatte, dem Kabel oder… gegeben haben muss. Falsch geschriebene Daten werden obendrein von den meisten Dateisystem gar nicht erkannt, erkannt werden können in den meisten Fällen höchstens falsche oder inkosistente Metadaten. Dann kann man zwar das Dateisystem wieder in einen konsistenten Zustand bringen, aber das sagt nichts darüber aus in welchem Zustand die Datei sind.
Aus dem Grund finde ich gerade die Prüfsummen über die Daten bei zfs, btrfs oder nilfs sehr interessant und überzeugend...
Antworten auf deine eigentliche Frage fällt mir nicht besonders viel ein:
- /var/log/fsck/
- journalctl:
Wenn bei dir /var/log/journal existiert hat systemd möglicherweise alle Meldungen von fsck aufgezeichnet. Die müssten sich dann mit
oder vielleicht
anzeigen lassen (ich tue mir schwer, weil mir bei mir alle diese Logs leer sind).
Wenn du aber fsck manuell in der Konsole gestartet hast, sind die Meldungen womöglich auf nimmerwiedersehen weg - ich vermute du hättest beim Aufruf von fsck (ev. mit -v) selbst für das Aufzeichnen der Meldungen sorgen müssen.
Dann kann der Vorfall vor 2-3 Tagen ja (fast?) nicht schuld daran sein und ich würde vermuten, dass es davor schon Probleme mit der Festplatte, dem Kabel oder… gegeben haben muss. Falsch geschriebene Daten werden obendrein von den meisten Dateisystem gar nicht erkannt, erkannt werden können in den meisten Fällen höchstens falsche oder inkosistente Metadaten. Dann kann man zwar das Dateisystem wieder in einen konsistenten Zustand bringen, aber das sagt nichts darüber aus in welchem Zustand die Datei sind.
Aus dem Grund finde ich gerade die Prüfsummen über die Daten bei zfs, btrfs oder nilfs sehr interessant und überzeugend...
Antworten auf deine eigentliche Frage fällt mir nicht besonders viel ein:
- /var/log/fsck/
- journalctl:
Wenn bei dir /var/log/journal existiert hat systemd möglicherweise alle Meldungen von fsck aufgezeichnet. Die müssten sich dann mit
Code: Alles auswählen
# journalctl -p7 _EXE=/sbin/fsck
# journalctl -p7 _EXE=/sbin/fsck.ext4
Code: Alles auswählen
# journalctl -p7 -u systemd-fsck-root
Wenn du aber fsck manuell in der Konsole gestartet hast, sind die Meldungen womöglich auf nimmerwiedersehen weg - ich vermute du hättest beim Aufruf von fsck (ev. mit -v) selbst für das Aufzeichnen der Meldungen sorgen müssen.