NetBackup MSDP log files
The NetBackup deduplication components write information to various log files. Some NetBackup commands or processes write messages to their own log files. Other processes use Other processes use Veritas Unified Logging (VxUL) log files. VxUL uses a standardized name and file format for log files. An originator ID (OID) identifies the process that writes the log messages.
See About legacy logging.
In VxUL logs, the messages that begin with an sts prefix relate to the interaction with the deduplication plug-in. Most interaction occurs on the NetBackup media servers. To view and manage VxUL log files, you must use NetBackup log commands. For information about how to use and manage logs on NetBackup servers, see the NetBackup Logging Reference Guide. The guide is available through the following URL:
Most interaction occurs on the NetBackup media servers. Therefore, the log files on the media servers that you use for disk operations are of most interest.
Warning:
The higher the log level, the greater the affect on NetBackup performance. Use a log level of 5 (the highest) only when directed to do so by a Cohesity representative. A log level of 5 is for troubleshooting only.
Specify the NetBackup log levels in the host properties on the NetBackup primary server. The log levels for some processes specific to certain options are set in configuration files as described in Table: Logs for NetBackup MSDP activity.
Table: Logs for NetBackup MSDP activity describes the log files for each component.
Table: Logs for NetBackup MSDP activity
Component | VxUL OID | Description |
|---|---|---|
|
Backups and restores |
117 |
The nbjm Job Manager. |
|
Backups and restores |
N/A |
Messages appear in the log files for the following processes:
|
|
Catalog shadow copies |
N/A |
The MSDP catalog shadow copy process writes messages to the following log files and directories: UNIX: /storage_path/log/spad/spad.log /storage_path/log/spad/sched_CatalogBackup.log /storage_path/log/spad/client_name/ Windows: storage_path\log\spad\spad.log storage_path\log\spad\sched_CatalogBackup.log storage_path\log\spad\client_name\ |
|
Client deduplication proxy plug-in |
N/A |
The client deduplication proxy plug-in on the media server runs under bptm, bpstsinfo, and bpbrm processes. Examine the log files for those processes for proxy plug-in activity. The strings proxy or ProxyServer embedded in the log messages identify proxy server activity. They write log files to the following directories:
|
|
Client deduplication proxy server |
N/A |
The deduplication proxy server nbostpxy on the client writes messages to files in the following directory, as follows: UNIX: Windows: |
|
Deduplication configuration script |
N/A |
The following is the path name of the log file for the deduplication configuration script:
NetBackup creates this log file during the configuration process. If your configuration succeeded, you do not need to examine the log file. The only reason to look at the log file is if the configuration failed. If the configuration process fails after it creates and populates the storage directory, this log file identifies when the configuration failed. |
|
Deduplication plug-in |
N/A |
The DEBUGLOG entry and the LOGLEVEL in the
You can configure the location and name of the log file and the logging level. To do so, edit the DEBUGLOG entry and the LOGLEVEL entry in the |
|
Device configuration and monitoring |
111 |
The nbemm process. |
|
Device configuration and monitoring |
178 |
The Disk Service Manager process that runs in the Enterprise Media Manager (EMM) process. |
|
Device configuration and monitoring |
202 |
The storage server interface process that runs in the Remote Manager and Monitor Service. RMMS runs on media servers. |
|
Device configuration and monitoring |
230 |
The Remote Disk Service Manager interface (RDSM) that runs in the Remote Manager and Monitor Service. RMMS runs on media servers. |
|
drcontrol utility |
N/A |
You must run the drcontrol utility on the MSDP storage server host. The command requires administrator privileges. The utility creates a log file and displays its pathname in the command output. The utility writes log files to the following directory, depending on the operating system: UNIX: /[storage_path]/log/drcontrol/policy_admin /storage_path/log/drcontrol/dedupe_catalog_DR Windows: storage_path\log\drcontrol\policy_admin storage_path\log\drcontrol\dedupe_catalog_DR See About protecting the MSDP catalog.
|
|
Installation |
N/A |
The NetBackup installation process writes information about the installation of the deduplication components to a log file in the following directory:
|
|
NetBackup Deduplication Engine |
N/A |
The NetBackup Deduplication Engine writes several log files, as follows:
|
|
NetBackup Deduplication Engine |
364 |
The NetBackup Deduplication Engine that runs on the deduplication storage server. |
|
NetBackup Deduplication Manager |
N/A |
The log files are in the /storage_path/log/spad directory, as follows:
You can set the log level and retention period in the Change Storage Server dialog box Properties tab. |
|
Optimized duplication and replication |
N/A |
For optimized duplication and Auto Image Replication, The following are the log files that provide information:
|
|
Resilient network connections |
387 |
The Remote Network Transport Service (nbrntd) manages resilient network connection sockets. It runs on the primary server, on media servers, and on clients. Use the VxUL originator ID 387 to view information about the socket connections that NetBackup uses. Note: If multiple backup streams run concurrently, the Remote Network Transport Service writes a large amount of information to the log files. In such a scenario, Cohesity recommends that you set the logging level for OID 387 to 2 or less. To configure unified logs, see the NetBackup Logging Reference Guide. |
|
Resilient network connections |
N/A |
The deduplication plug-in logs information about keeping the connection alive. For more information about the deduplication plug-in log file, see "Deduplication plug-in" in this table. The |
The CRC notifications | N/A | The debug logs for CRC health check are saved at the following location:
|