Source: Tipps zur Fehlerbehebung bei Backups
Übersicht
Die Analyse von SEP sesam Protokolldateien ist sehr nützlich, um die Operationen zu erkennen, die Fehler oder Fehlfunktionen verursacht haben, z.B. im Falle einer erfolglosen Sicherung.
SEP sesam erstellt für jeden Sicherungstag zwei Protokolle bzw. Protokolldateien: die Statusdatei (<Tagesdatum>.status) und das Tagesprotokoll (<Tagesdatum>.prt). Ein Fehlerprotokoll (<Tagesdatum>.prt.err) ist eine Untermenge des Tagesprotokolls, in dem nur Fehlermeldungen aufgezeichnet werden.
Protokolldateien können ausgedruckt oder per E-Mail versendet werden. Das Verzeichnis, in dem die Protokolldateien gespeichert sind, ist <SEPsesam>/VAR/prot. Sie können die Sicherungsprotokolle (Status, Tag oder Fehler) in der GUI (Auswahl -> Protokolle -> Status/Tagesprotokoll/Fehlerprotokoll) und in der Web UI überprüfen. Details finden Sie unter SEP sesam Web UI.
Tipps zur Fehlerbehebung bei Sicherungen
Im Falle einer erfolglosen Sicherung sollten Sie die folgenden Tipps beachten:
- Ermitteln Sie anhand des Tagesprotokolls (.prt) und des Statusprotokolls (.status), wann das Problem aufgetreten ist. Das Tagesprotokoll zeigt den kausalen Verlauf aller SEP sesam Aktivitäten des Sicherungstages. Die Dateien mit der Endung .prt.err enthalten nur die Fehlermeldungen als Teilmenge des Tagesprotokolls.
- Zeigen Sie die Verzeichnisdateien chronologisch an (mit ls -lart unter Linux).
- Generell sollten die Protokolldateien von unten gelesen werden. Wenn eine Sicherung fehlgeschlagen ist, finden Sie mögliche Hinweise auf Fehler und deren Ursachen in der Regel am Ende der entsprechenden Protokolldatei.
- Vergleichen Sie nicht funktionierende und funktionierende Sicherungen:
- Prüfen Sie, wann die letzte erfolgreiche Sicherung dieses Auftrags durchgeführt wurde.
- Finden Sie die Unterschiede zwischen not- und bck-Protokollen in den beiden verschiedenen Sicherungen.
- Finden Sie heraus, ob Änderungen im Netzwerk oder auf dem Client vorgenommen wurden.
- Die Werte der Datenbankaufrufe in DB_ACCESS (in den Protokolldateien) werden im folgenden erläutert:
- result = 1: Der Datenbankzugriff ist OK.
- msg > 0: Betrag des Ergebnisses > 0.
- Wenn der Datendurchsatz sehr gering ist und die Sicherung immer noch nicht läuft, kann es sein, dass die Kommunikation zwischen Hardware und RDS gestört ist. Prüfen Sie mit netstat, ob die Verbindung über die STP-Ports (11001, 11002, etc.) noch besteht oder ob der RDS noch erreichbar ist.
- Wenn ein Prozess versucht, auf die Hardware zu schreiben und hängt, hilft der Befehl kill -9 unter Linux nicht weiter. Die einzige Lösung ist ein Neustart des Servers. Der Grund dafür ist die Tatsache, dass I/O-Requests nicht zurückkommen. Diese Prozesse dauern in der Regel nur Sekundenbruchteile, hängen aber bei einem Hardwarefehler.
- SEP sesam verwendet keine Kernelfunktionen und greift während der Verarbeitung nicht auf den Kernel zu. Alle Aufrufe erfolgen ausschließlich über GLIBC (GNU C Library). Das Kommando, das am tiefsten ins System eingreift, ist das SLU (SCSI Lader Utility). Es greift direkt auf die SCSI-Schnittstelle zu. Nur Lader- und Band-Transport-Befehle sind davon betroffen. Wenn eine Sicherung läuft, dann gibt es keinen direkten Zugriff auf den Kernel oder die Hardware mit SEP sesam. Einzelheiten zum Befehl finden Sie unter Verwendung von slu-Topologie für die Erkennung von Geräten.