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 people 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.
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.
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.
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.