Remote Backup System Log files.

The Remote Backup system works flawlessly out of the box in the vast majority of situations. Occasionally, however, one of a variety of issues may occasionally arise, and knowledge of the Log Files and how they are used will help you to diagnose and correct the issue.

Should it prove difficult, the log files can communicate details to us to use in assisting you, often tipping us off immediately to what will resolve the trouble.

You should also be aware of these log files, because in regular system maintenance, you may wish to review and archive or purge them. Some of them can grow quite large, and because they can help you to understand how the system works to a greater extent.


Server-Side Logs:

The Server provides two (2) primary log files that track specific information, these are:

the RBS Audit Log is named DRBS(date).log.
For example, the Oct 1, 2002 log would be DRBS20021001.LOG.

The RBS Audit Log records general operational messages produced by the server as it receives backups. The level of detail written to the log varies with the Server's Log Level setting. Log Level settings are Standard, Detailed and Verbose and are found on the Properties, Manager Preferences screen.

Log Levels control the amount of detail

At LogLevel=Standard only the most basic entries are recorded. Detailed and Verbose show considerably more. In normal operation standard will only contain informational and occasional error messages, detailed will list each file to the Transaction Log. Verbose provides the most comprehensive level for troubleshooting or the most detailed monitoring.

IP Logs - The Server's record of a connection.

Each endpoint that connects to your server also records into a log file. The contents of this log file are not affected by the Log Level setting and represents the server-side of the connection with that particular endpoint. Our Server Tester, for example, will create a log file named 216.37.73.233.Log. If you have trouble with responses from the tester, this log may help to explain them.


Client-Side (endpoint) Logs:

The endpoint program also produces logs. There are two or three logs that may be written to, depending on the settings of Log Level.

1. Session Log - General running log of endpoint activity, affected by Log Level setting

SessionLog.txt - This log records general messages. It is accessable from the menu (View, Logs, SessionLog) and receives output from Test Connections, Estiator and other processes as well as general messages of the Remote Backup endpoint.

When the date changes, the previous days SessionLog.txt file is renamed SESS (date).log and is automatically purged after a few days, to keep it from growing to infinity.

2. Backup Log - Same format as Session Log, but one is produced specifically for each Backup Run, also affected by Log Level setting.

The Backup Log - Each backup creates a log of that specific backup. This log also depends on the level setting as to the amount of detail it produces. The backup log is named on the date, and by the Backup Code used, it starts with the year, an example would be: 2002100103C1243.LOG. These are also purged after 3 days.

3. Trace Log - trace of connection with server, not affected by log level setting, only produced at Loglevel = Trace.

The TRACE log is produced ONLY when the endpoint log level setting is TRACE. Other logs will also show extra details when Trace mode is active.


How do I use them?

Generally, you should use the logs to support the type of activity you are troubleshooting. In general if it is a connection issue, the TRACE and Session Log on TRACE mode will provide many details. If the endpoint can connect to the server, the ip log corresponding to the endpoints IP address, may also prove useful.

If the issue regards the selection of files or other areas, which are far less common than connection issues, you might want to run in DETAILED mode on the endpoint or server. You can always do a small run and check the entries to see if they have produced anything useful.

Hack Attacks?

If your port is 21 or even if not, you may see evidence of unauthorized access attempts in your log files. The IP Logs should be regularly inspected to see if they are valid endpoints or not. The system will not allow them in if the login is incorrect, but it does record the attempts. If you use a firewall, and you see repeated attempts from an identifiable IP address, you can specifically block that address at the firewall.

Bad Logins?

If your endpoint just won't login and you're sure the Username, Password and Account Group are correct, and you continue to get 530 Invalid Log messages, the TRACE mode log or the Server IP Log can both help point you in the right direction.

Error 500?

If you see error 500 in your log, it's most likely from an endpoint that tried to connect in ACTIVE mode, but is behind a firewall or router. In this case, the endpoint should switch to PASSIVE mode automatically. If the client runs a test connection the program will self-correct this.

Error 550 ?

You may see error 550 on the server. While expected in normal operation, it is suppressed on the endpoint. It can mean a requested file is not there, but also is expected in normal use of the system. It is more efficient for the endpoint to receive an error when trying to change directory, upon which it creates the directory - so in this one case, the endpoint's reporting of 550 is expected and normal.

Error 425 ?

The Server generally finds you an open port, but if the server sends a port that's not available, a 425 error will result. Don't worry though, the system will just request the next port. If your port range is accurate, this should be very rare.