How to Gather Information

 < Day Day Up > 



Things to Check before Calling Your Dedicated Support Professional

Usually, we think about troubleshooting problems after things have failed. A little planning in the beginning really helps. Most backup applications have the ability to create their own specific logs. You need to know how logging works within your application and be prepared to enable logging. The authors usually enable all logging during the initial installation so we have the appropriate logs if our initial attempts at backups and restores are not successful. After things are looking good, you should reduce or shut down logging. In some instances there can be a performance impact from logging, and in all instances the logs will consume disk space.

You also need to know how each operating system in your environment handles warning, error, and normal messages. You will discover that just about every operating system will handle these a little differently by default. On most UNIX systems you can see how the system will handle logging by looking at the /etc/syslog.conf file. Here is a sample of this file from a Solaris system:

 #ident  "@(#)syslog.conf       1.5       99/02/03 SMI"    /* SunOS 5.0 */  #  # Copyright (c) 1991-1999 by Sun Microsystems, Inc.  #  # syslog configuration file.  #  # This file is processed by m4 so be careful to quote (`') names  # that match m4 reserved words.  Also, within ifdef's, arguments  # containing commas must be quoted.  #  *.err;kern.notice;auth.notice                   /dev/sysmsg  *.err;kern.debug;daemon.notice;mail.crit        /var/adm/messages  *.alert;kern.err;daemon.err                     operator  *.alert                                         root  *.emerg                                         *  # if a non-loghost machine chooses to have authentication messages  # sent to the loghost machine, un-comment out the following line:  #auth.notice                    ifdef(`LOGHOST', /var/log/authlog,  @loghost)  mail.debug                      ifdef(`LOGHOST', /var/log/syslog,  @loghost)  #  # non-loghost machines will use the following lines to cause "user"  # log messages to be logged locally.  #  ifdef(`LOGHOST', ,  user.err                                        /dev/sysmsg  user.err                                        /var/adm/messages  user.alert                                      `root, operator'  user.emerg                                      *  ) 

As you can see, most of the messages you are interested in are logged to /var/adm/messages. On an HP-UX system you will see something completely different. Here is a sample /etc/syslog.conf file from an HP system:

 # @(#) $Revision: 74.1 $  #  # syslogd configuration file.  #  # See syslogd(1M) for information about the format of this file.  #  mail.debug              /var/adm/syslog/mail.log  *.info;mail.none        /var/adm/syslog/syslog.log  *.alert                 /dev/console  *.alert                 root  *.emerg                 * 

You are really looking for two things: the location of the log file and making sure it is not disabled. If there is a hash (#) in the first column, then that line is commented out. By default, some systems have all the logging lines in the /etc/syslog.conf file commented out. You should enable the appropriate lines to ensure logging is turned on. This log is where you would see if the system is reporting problems, along with some of the processes that are running as part of the backup application as they also log to the system log. On Windows systems, the application will usually have its own logs. In addition, you will need to use the event viewer to access the system logs and the application logs. You should also be familiar with network error logging, since the network can play a very large role in backing and recovering systems. The netstat command is commonly used to get a basic idea of the condition of your network. Here is a sample netstat command output on a Solaris system:

 # netstat -i  Name  Mtu  Net/Dest      Address        Ipkts    Ierrs    Opkts  Oerrs  Collis Queue  lo0      8232 loopback      localhost      434768   0     434768    0  0       0  hme0  1500 burreed         burreed        280473   0     254050    0  546     0 

Your backup application should also include a troubleshooting manual that will provide helpful information, including a list of error codes and recommended actions. If you have a backup or restore failure, you can look up the specific error code and get an idea of where the problem might lie. If it appears to be network related, you should make sure you have good network connectivity between the systems involved. You could go to each system and see what the network logs show. The troubleshooting manual might also suggest some commands to try. As you investigate, be sure to gather all the logging information as well as configuration information, so when you call the support hotline, you will already have the information that the support person needs to assist you.



 < Day Day Up > 



Implementing Backup and Recovery(c) The Readiness Guide for the Enterprise
Implementing Backup and Recovery: The Readiness Guide for the Enterprise
ISBN: 0471227145
EAN: 2147483647
Year: 2005
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net