AWS / Azure

The fields are as follows:

  • Staging Directory. A directory on the local file system that is large enough to accommodate approximately 10% of the data set that is to be backed up. A minimum of 50 GB is recommended. The pathname of the location must be accessible to all nodes in the cluster that are running the Backup Service, but the location itself must not be shared by NFS or any equivalent protocol. Instead, the location must be a non-shared directory on the local file system for the node.

  • Provider. To use either S3 or S3-compatible storage, select AWS.

  • Cloud Bucket. The bucket in the cloud to which data will be backed up.

  • Path Prefix. The path of the archive, within the cloud bucket. This should take the form /path/inside/the/bucket.

  • Cloud Auth Type The type of authentication to be used when communicating with the cloud provider. The options are ID and key (which means that an ID and key will indeed be required for communication to be successful) and Instance metadata service (which means that credentials will be sought from the metadata service running in the node’s virtual machine). Each option assumes that appropriate configuration procedures for the cloud environment have been followed.

  • Credential ID. The credential ID for the store. For AWS, this is the access key id. If Instance metadata service has been specified as the value for Cloud Auth Type, this field is inapplicable, and is no longer displayed.

  • Credential Key. The secret key for the store. For AWS, this is the AWS secret access key. If Instance metadata service has been specified as the value for Cloud Auth Type, this field is inapplicable, and is no longer displayed.

  • Region. The AWS Region for the repository. For example, us-east-1, us-west-2.

Under Advanced cloud options, the Endpoint field accepts an optional endpoint, used to connect to AWS; and overriding the endpoint used by the cloud-provider.

If checked, the S3 Force path style checkbox ensures that the AWS path style used is the earlier (rather than the more recent, which is not supported by all S3 compatible object stores).

GCP

Before setting up the GCP cloud backup, you will first need to get an Oauth token and a refresh token associated with your GCP service. To do this, follow these steps.

  1. Retrieve the client id and the client secret.

    1. Access the console under your GCP account, select menu:API & Services[Credentials]

    2. Create an`Oauth` token for use with the Couchbase backup service.

    3. Create a service account for use with the Couchbase backup service.

    4. Select the Oauth Client ID you wish to use and click the btn:[Download] link. From the resulting dialog, download the JSON file which contains the client ID and the client secret. The file contains the client information you will need for the next step:

      {
    "installed": {
        "client_id": "<client_id>",
        "project_id": "<project_id>",
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_secret": "<client_secret>",
        "redirect_uris": [
            "http://localhost"
        ]
    }
}

    5. This is line @2

    6. This is line @3

  2. Retrieve the OAUTH credentials.

    Use the client_id and the client_secret obtained in the previous section as parameters in a shell command that will return the refresh token for the backup service. This involves interrogating the GCP service to extract a refresh token for your OAuth client ID.

    1. Create a shell script containing the following commands:

      CLIENT_ID= "<client_id>"
CLIENT_SECRET="<client_secret>"
SCOPE="https://www.googleapis.com/auth/devstorage.read_write"
ENDPOINT="https://accounts.google.com/o/oauth2/v2/auth"
URL="$ENDPOINT?client_id=$CLIENT_ID&response_type=code&scope=$SCOPE&access_type=offline&redirect_uri=http://localhost:12345"
open $URL

    2. Save the script with a .sh extension (e.g., oauth.sh)

    3. Execute the chmod command to make the script executable.

      chmod u+x ./oauth.sh

    4. Now execute the script.

      ./oauth.sh

      The script will open your default browser; you can copy the oauth credential from the string in the browser URL input field.

      Tip
      		 You may need to click through a few pages, until you see https:localhost:12345 in the URL field.

      Copy the string denoted by the code field for use in the next section.

  3. Generate the Refresh Token

Now, you will create a short shell script, using te oauth credentials you retrieved in the previous section.

  1. Create a new shell script for generating the refresh token.

    CLIENT_ID= "<client_id>"
CLIENT_SECRET= "<client_secret>"
AUTH_CODE= "<oauth_code>"
curl -s -X POST https://www.googleapis.com/oauth2/v4/token --data-urlencode "client_id=$CLIENT_ID" --data-urlencode "client_secret=$CLIENT_SECRET" --data-urlencode "code=$AUTH_CODE" --data-urlencode "redirect_uri=http://localhost:12345" --data-urlencode "grant_type=authorization_code"

    Fill in the client_id and the the client_secret you retrieved from this section, and the oauth token you generated here.

  2. Save the script with an .sh extension (e.g., refresh.sh).

  3. Execute the chmod command to make the script executable.

    chmod u+x ./refresh.sh

  4. Execute the script.

    ./refresh.sh

    You will receive a response written to the console that contains the refresh token. Make a note of the refresh token.

    {
  "access_token": "ya29.a0AXooCgu19SsugltQz_x46dK347ZBCUMW4n4N9YKFbQVD5kNWWpSyOSCMWjW6KAksa6rwaM8Dra9wH_jvzYG9TeLn4RCfICXwRD5U3WNNCWqy0lRiXPgjEQnXO9S-PnxGBe7hSsriKBpeZzWRXKVlnK56vDrzFcdY0DwRaCgYKAQESARISFQHGX2Mi0WeT_pBPR_RVpwOqCQg4gw0171",
  "expires_in": 3599,
  "refresh_token": "1//03Dd3-R0ojbfWCgYIARAAGAMSNwF-L9Ir0ei97UZf5kLz4pWXxNRB3mljmS0Kfz1ykzJe7_UYKqVieI6dBb3o66CeNQGtq9HleFo",
  "scope": "https://www.googleapis.com/auth/devstorage.read_write",
  "token_type": "Bearer"
}