Backup Storages

Back up snapshot data to GCS

./br backup full --pd "${PD_IP}:2379" \
--storage "gcs://external/backup-20220915?credentials-file=${credentials-file-path}"

Restore snapshot data from GCS

./br restore full --pd "${PD_IP}:2379" \
--storage "gcs://external/backup-20220915?credentials-file=${credentials-file-path}"

Back up snapshot data to Azure Blob Storage

./br backup full -u "${PD_IP}:2379" \
--storage "azure://external/backup-20220915?account-name=${account-name}&account-key=${account-key}"

Restore the test database from snapshot backup data in Azure Blob Storage

./br restore db --db test -u "${PD_IP}:2379" \
--storage "azure://external/backup-20220915account-name=${account-name}&account-key=${account-key}"

You can configure the account used to access GCS by specifying the access key. If you specify the credentials-file parameter, the authentication is performed using the specified credentials-file. Besides specifying the key in the URI, the following methods are also supported:

• BR reads the file in the path specified by the environment variable $GOOGLE_APPLICATION_CREDENTIALS
• BR reads the file ~/.config/gcloud/application_default_credentials.json.
• BR obtains the credentials from the metadata server when the cluster is running in GCE or GAE.

• Method 1: Specify the shared access signature

  If you specify account-name and sas-token in the URI, the authentication is performed using the specified account name and shared access signature (SAS) token. Note that the SAS token contains the & character. You need to encode it as %26 before appending it to the URI. You can also directly encode the entire sas-token using percent-encoding.

• Method 2: Specify the access key

  If you specify account-name and account-key in the URI, the authentication is performed using the specified account name and account key. Besides the method of specifying the key in the URI, BR can also read the key from the environment variable $AZURE_STORAGE_KEY.

• Method 3: Use Azure AD for backup and restore

  Configure the environment variables $AZURE_CLIENT_ID, $AZURE_TENANT_ID, and $AZURE_CLIENT_SECRET on the node where BR is running.

  • When the cluster is started using TiUP, TiKV uses the systemd service. The following example shows how to configure the preceding three environment variables for TiKV:

    Note

    If this method is used, you need to restart TiKV in step 3. If your cluster cannot be restarted, use Method 1: Specify the access key for backup and restore.

    1. Suppose that the TiKV port on this node is 24000, that is, the name of the systemd service is tikv-24000:

       systemctl edit tikv-24000
       

    2. Edit the TiKV configuration file to configure the three environment variables:

       [Service]
       Environment="AZURE_CLIENT_ID=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
       Environment="AZURE_TENANT_ID=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
       Environment="AZURE_CLIENT_SECRET=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
       

    3. Reload the configuration and restart TiKV:

       systemctl daemon-reload
       systemctl restart tikv-24000
       

  • To configure the Azure AD information for TiKV and BR started with command lines, you only need to check whether the environment variables $AZURE_CLIENT_ID, $AZURE_TENANT_ID, and $AZURE_CLIENT_SECRET are configured in the operating environment by running the following commands:

    echo $AZURE_CLIENT_ID
    echo $AZURE_TENANT_ID
    echo $AZURE_CLIENT_SECRET
    

  • Use BR to back up data to Azure Blob Storage:

    ./br backup full -u "${PD_IP}:2379" \
    --storage "azure://external/backup-20220915?account-name=${account-name}"