Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. Cohesity Cloud Scale Technology Manual Deployment Guide for Kubernetes Clusters
  3. Section III. Monitoring and Management
  4. Managing logging
  5. Extracting NetBackup logs
Cohesity Cloud Scale Technology Manual Deployment Guide for Kubernetes Clusters

Extracting NetBackup logs

You can extract NetBackup logs from the Cloud Scale environment using the following options:

  • (Recommended) Use the NetBackup Troubleshooting APIs for log extraction requests

  • Copy logs out of the log-viewer using the kubectl commands

  • Copy logs out if the log-viewer or nbwsapp are not working

Extracting logs via NetBackup Troubleshooting APIs

NetBackup Cloud Scale Technology introduced log extraction APIs in version 11.0 to assist in extracting logs from a Cloud Scale environment.

Table: Extract logs via APIs

Action

Command / Description

In order to extract logs via the APIs you must go through a series of calls to create a request and extract the logs. All API endpoints require a valid JWT Authorization header.

  1. Create Async Request: Create the request. Use the filters described below to specify specific log types to extract.

    See Location Header for Async Request ID.

    POST /netbackup/troubleshooting/async-log-download-requests

  2. Get Async Request Status: Check the status of the previous request.

    See Location Header for Async Result ID.

    GET /netbackup/admin/async-requests/<async_request_status_id>

  3. Get Async Request Result (Usually done via redirect): Gets the Async Request Result.

    See Location Header for Log Download Request ID.

    GET /netbackup/troubleshooting/async-log-download-requests-results/<async_result_id>

  4. Get Log Download Request: This retrieves the Log Download Request information.

    See data.relationships.archive.links.related.href for URL to download logs.

    GET /netbackup/troubleshooting/log-download-requests/<log_download_request_id>

  5. Download Log Download Request Archive: This downloads the logs.

    /netbackup/troubleshooting/log-download-requests/<log_download_request_id>/logs/netbackup-logs.zip

Filtering: The Create Async Request endpoint has filters that can be applied to target specific logs that the user wants to gather.

Following filters exist:

globalFilter

  • startTime: The start timestamp to look for files.

  • endTime: The end timestamp to look for files.

  • namespaces: A list of kubernetes namespaces to extract logs from.

legacyLogFilter

directories: Legacy log directories to pull logs from.

unifiedLogFilter

fileIds: A list of UL file ID's to pull logs from.

It is recommended to use the provided filters to be specific about log request in order to avoid timeout. Default: 60 min

Note:

All the filters are optional and have an AND relationship. This indicates that if you provide filters from multiple categories, they must match all the categories to be considered valid for extraction.

Limitations

Among the filtering options specified above, globalFilter is applicable to every log. But legacyLogFilter and unifiedLogFilter is applicable only to logs that are part of those specific categories.

For example, if you applied a date range via globalFilters and applied a legacyLogFilter and a unifiedLogFilter then you would get all legacy logs that fit the legacyLogFilter and the globalFilters and all unified logs that fit the unifiedLogFilter and the global filters.

By default, some of the logs have long names and long paths. This can cause issues on windows when extracting the logs on a windows computer. Hence the logs would be skipped and would not be a part of the resultant unzipped folder. Hence it is recommended that you extract these logs onto a Linux based file system.

Extract logs via kubectl cp commands

In order to extract the logs out of the log-viewer pod there are a few options. You can tar and compress the logs before extraction or extract them immediately.

  1. (Optional) Tar up the files you want to extract. Select a folder and run:

    $ tar -cvf <name of tar> <name of folder>

  2. Copy the files out of the container. Exit the container using the command:

    $ kubectl cp -n netbackup <pod-name>:/usr/openv/fluentbit/logs/<folder or tar> <output folder or tar>

  3. (Optional) Extract the tar outside the container if necessary:

    $ tar xvf <output tar>

Extracting logs if nbwsapp or log-viewer pods are not working

If nbwsapp or log-viewer pods are not working, then you need to extract logs from other pods. Use the following command to copy logs out of the pods:

$ kubectl cp -n netbackup <pod-name>:/usr/openv/fluentbit/logs/<folder or tar> <output folder or tar>

The first pod to try must be fluentbit collector pod as it also mounts the file system storing all the Cloud Scale logs. If the fluentbit collector pod is not working you will need to copy the logs directly from individual application pods such as nbwsapp or primary. Logs within application pods are usually stored at /mnt/nblogs directory.

Feedback

Was this page helpful?
Previous

Viewing NetBackup logs

Next

Performing catalog backup and recovery

Feedback

Was this page helpful?