A newer version of this documentation is available.

View Latest

cbbackupmgr collect-logs

      +

      Collects debugging information from a backup archive

      SYNOPSIS

      cbbackupmgr collect-logs [--archive <archive_dir>] [--output-dir <dir>]
                               [--redact] [--salt <salt>] [--upload-host <url>]
                               [--customer <customer-name>] [--upload-proxy <proxy>]
                               [--ticket <ticket-number>] [--obj-access-key-id <access_key_id>]
                               [--obj-cacert <cert_path>] [--obj-endpoint <endpoint>]
                               [--obj-no-ssl-verify] [--obj-region <region>]
                               [--obj-staging-dir <staging_dir>] [--obj-secret-access-key <secret_access_key>]
                               [--s3-force-path-style]

      DESCRIPTION

      Collects debugging information to make it easier to debug user issues. This command collects the logs, the output of the info command, the range.json files from each backup, the seqnos and failover logs from each backup, and the backup_meta.json files from each repo. This data is put into a zip file that contains the date that the collect-info command was run. This command will only collect meta from the backup archive.

      OPTIONS

      Below are a list of parameters for the compact command.

      Required

      -a,--archive <archive_dir>

      The location of the archive directory.

      -o,--output-dir <dir>

      Specifies a path where the zip file that this command writes should be written. If this flag is not used then the zip file is written to the logs directory of the archive the command is run against.

      Optional

      --redact

      When the redact flag is specified a redacted copy of the logs will be produced, in the same directory as the unredacted version. The redacted zip directory will be prefixed by `redacted-`.

      --salt <salt>

      Specifies the salt to used to hash the data. If possible the salt should be the same used by Couchbase Server to allow the logs to be easily cross referenced. The Couchbase Server salt is at the top of the couchbase.log in the zip file generated by cbcollect_info. If no salt is specified it will be auto-generated.

      --upload-host <url>

      Specifies the fully-qualified domain name of the host you want the logs uploaded to. The protocol prefix of the domain name, https://, is optional. It is the default-only supported protocol.

      --customer <customer-name>

      Specifies the customer name. This value must be a string whose maximum length is 50 characters. Only the following characters can be used: [A-Za-z0-9_.-]. If any other characters are included, the request is rejected.

      --upload-proxy <upload-proxy>

      Specifies a proxy for upload.

      --ticket <ticket-number>

      Specifies the Couchbase Support ticket-number. The value must be a string with a maximum length of 7 characters, containing only digits in the range of 0-9.

      Cloud integration

      Native cloud integration is an Enterprise Edition feature which was introduced in Couchbase Server 6.6.0.

      Multiple cloud providers are supported, see the list below for more information.

      1. Supported

        • AWS S3 (s3://)

        • GCP Google Storage (gs://)

      2. Developer Preview

        • Azure Blob Storage (az://)

      Required

      --obj-staging-dir <staging_dir>

      When performing an operation on an archive which is located in the cloud such as AWS, the staging directory is used to store local meta data files. This directory can be temporary (it’s not treated as a persistent store) and is only used during the backup. NOTE: Do not use /tmp as the obj-staging-dir. See Disk requirements in cbbackupmgr-cloud for more information.

      Optional

      --obj-access-key-id <access_key_id>

      The access key id which has access to your chosen object store. This option can be omitted when using the shared config functionality provided by your chosen object store. Can alternatively be provided using the CB_OBJSTORE_ACCESS_KEY_ID environment variable.

      When using AWS, this option expects an access key id. See https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys for more information.

      When using Azure, this option expects an account name. See https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview#storage-account-endpoints for more information.

      When using GCP, this option expects a client id. See https://cloud.google.com/storage/docs/authentication for more information.

      --obj-cacert <cert_path>

      Specifies a CA certificate that will be used to verify the identity of the object store being connected to.

      --obj-endpoint <endpoint>

      The host/address of your object store.

      --obj-no-ssl-verify

      Skips the SSL verification phase when connecting to the object store. Specifying this flag will allow a connection using SSL encryption, but you are vulnerable to a man-in-the-middle attack.

      --obj-region <region>

      The region in which your bucket/container resides. For AWS this option may be omitted when using the shared config functionality. See the AWS section of the cloud documentation for more information.

      --obj-secret-access-key <secret_access_key>

      The secret access key which has access to you chosen object store. This option can be omitted when using the shared config functionality provided by your chosen object store. Can alternatively be provided using the CB_OBJSTORE_SECRET_ACCESS_KEY environment variable.

      When using AWS, this option expects a secret access key. See https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys for more information.

      When using Azure, this option expects an account key. See https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal for more information.

      When using GCP, this option expects a client secret. See https://cloud.google.com/storage/docs/authentication for more information.

      --obj-log-level <level>

      Set the log level for the cloud providers SDK. By default logging will be disabled. Valid options are cloud provider specific and are listed below.

      The valid options for the AWS SDK are debug, debug-with-signing, debug-with-body, debug-with-request-retries, debug-with-request-errors, and debug-with-event-stream-body.

      The valid options for the Azure SDK are info, debug, debug-with-request-retries and debug-with-request-retries-and-lro.

      The Google Storage SDK does not expose advanced logging configuration meaning this option is explicitly ignored, however, this behavior may change in the future.

      --obj-auth-by-instance-metadata

      Depending on the cloud provider, using instance metadata for authentication is disabled by default. Supplying this flag will allow the fetching credentials/auth tokens from (VM) internal instance metadata endpoints.

      By default, this option is disabled for AWS.

      By default, this option is enabled for Azure.

      By default, this option is enabled for GCP.

      --obj-auth-file

      GCP offers the ability to use a file which contains credentials which will be used to perform authentication. The --obj-auth-file flag accepts a path to an authentication file. This flag is unsupported for the AWS/Azure cloud providers.

      --obj-refresh-token

      GCP requires a refresh token when using static credentials, this will be used to refresh oauth2 tokens when accessing remote storage.

      AWS S3 Options

      Optional
      --s3-force-path-style

      By default the updated virtual style paths will be used when interfacing with AWS S3. This option will force the AWS SDK to use the alternative path style URLs which are often required by S3 compatible object stores.

      EXAMPLES

      To generate debugging information for an archive dir "/data/backup" and output the file to "/data/output/logs" run the following command.

      $ cbbackupmgr collect-logs -a /data/backup

      To generate debugging information for an archive dir "/data/backup" and output the file to "/tmp" run the following command.

      $ cbbackupmgr collect-logs -a /data/backup -o /tmp

      To upload the logs directly to support use:

      $ cbbackupmgr collect-logs -a /data/backup -o /tmp \
        --upload-host uploads.couchbase.com \
      --customer CUSTOMER_NAME --ticket 378211

      ENVIRONMENT AND CONFIGURATION VARIABLES

      CB_ARCHIVE_PATH

      Specifies the path to the backup archive. If the archive path is supplied as a command line argument then this value is overridden.

      CB_OBJSTORE_STAGING_DIRECTORY

      Specifies the path to the staging directory. If the --obj-staging-dir argument is provided in the command line then this value is overridden.

      CB_OBJSTORE_REGION

      Specifies the object store region. If the --obj-region argument is provided in the command line then this value is overridden.

      CB_OBJSTORE_ACCESS_KEY_ID

      Specifies the object store access key id. If the --obj-access-key-id argument is provided in the command line this value is overridden.

      CB_OBJSTORE_SECRET_ACCESS_KEY

      Specifies the object store secret access key. If the --obj-secret-access-key argument is provided in the command line this value is overridden.

      CB_OBJSTORE_REFRESH_TOKEN

      Specifies the refresh token to use. If the --obj-refresh-token argument is provided in the command line, this value is overridden.

      CB_AWS_ENABLE_EC2_METADATA

      By default cbbackupmgr will disable fetching EC2 instance metadata. Setting this environment variable to true will allow the AWS SDK to fetch metadata from the EC2 instance endpoint.

      SEE ALSO

      CBBACKUPMGR

      Part of the cbbackupmgr suite