Source:Troubleshooting Tips for Backup

From SEPsesam
Other languages:

Overview

The analysis of SEP sesam log files is very useful to determine the operations led to errors or failures, for example, in the case of a failed backup.

SEP sesam creates two protocols or log files for each backup day: the status file (<date of day>.status) and the day log (<date of day>.prt). An error log (<date of day>) is a subset of the day log, where only error messages are recorded.

The log files can be printed or sent by email. The directory where the log files are stored is <SEPsesam>/VAR/prot. You can check backup logs (state, day or error) in the GUI (Main Selection -> Logging -> State/Day Log/Error Log) and in Web UI. For details, see SEP sesam Web UI.

Tips for backup troubleshooting

In case of a failed backup, you should follow the tips below:

  • Find out when the problem occurred using the day log (.prt) and the status log (.status). The day log shows the causal progression of all SEP sesam activities of the backup day. The files with a file extension ending in .prt.err contain only the error messages from the day log.
  • Display the directory files chronologically (with ls -lart on Linux).
  • The log files should be read backwards from the end of the file. If a backup failed, you can usually find the indication of errors and their causes at the end of the respective log file.
  • Compare failed backups with working backups:
    • Check when the last successful backup of this task took place.
    • Identify the differences between not and bck logs by comparing two different backups.
    • Determine if there were any changes on the network or on the client.
  • The values of the database calls in DB_ACCESS have the following explanations:
    1. result = 1: Database access is OK.
    2. msg > 0: Amount of result > 0.
  • If the data throughput is very low and no backup is running, communication between hardware and RDS may have stopped . Use netstat to check if the connection over the STP ports (11001, 11002, etc.) still exists and check if RDS is still reachable.
  • If a process attempts to write to the hardware device and hangs, the kill -9 command on Linux will not help because the process is waiting for I/O and the kernel is unable to stop it. The only solution is to restart the server. These processes usually take only fractions of a second, but get stuck if there are hardware problems.
  • SEP sesam does not use kernel functions nor does it access the kernel while processing. All calls are done exclusively via GLIBC (GNU C Library). The command that goes deepest into the system is slu (SCSI Loader Utility). It accesses the SCSI interface directly. Only loader and tape mover commands are affected. When a backup is running, there is no direct access to the kernel or hardware with SEP sesam. For details about this command, see Using slu topology for detecting devices.
Copyright © SEP AG 1999-2024. All rights reserved.
Any form of reproduction of the contents or parts of this manual is allowed only with the express written permission from SEP AG. When compiling and designing user documentation SEP AG uses great diligence and attempts to deliver accurate and correct information. However, SEP AG cannot issue a guarantee for the contents of this manual.