Add a backup repository

A backup repository represents a compatible storage location for your backups. A backup repository is also used to store records of backups, backup plans, restore plans, and restores.

This page assumes that you have a compatible endpoint available and that you have created a bucket to use as the backup repository.

To get the permissions that you need to create a backup repository, ask your Organization IAM Admin to grant you the Backup Repository Admin (backup-repository-admin) role.

Create a repository

Create a repository by using the GDC console or the API.

Console

  1. Sign in to the GDC console.
  2. In the navigation menu, click Backup for Clusters. Ensure no project is selected in the project selector.
  3. Click Create repository.
  4. Enter a repository name. The description is optional.
  5. In the Main cluster (read/write) list, choose a cluster.
  6. In the Linked clusters (read only) list, choose the linked clusters.
  7. In the S3 URI endpoint field, enter an endpoint containing the fully-qualified domain name of your object storage site.
  8. In the Bucket name field, enter the name of the bucket.
  9. In the Bucket region field, enter the region where the bucket was created.
  10. In the Access Key ID list, enter the access key ID.
  11. In the Access key field, enter the access key.
  12. Click Create.

API

To use the backup and restore APIs, you must configure a valid BackupRepositoryManager custom resource to be the location of your backups, and supply the required credentials.

  1. Add the access-key and access-key-id as a secret in the target cluster. The secret must exist in the org admin cluster when setting up a BackupRepositoryManager custom resource. The BackupRepositoryManager custom resource propagates the secret to the necessary user clusters when it creates the backup repositories. For example:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: "s3-secret-ns"
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      namespace: "s3-secret-ns"
      name: "s3-secret"
    type: Opaque
    data:
      access-key-id: YWNjZXNzS2V5MQ== # echo -n accessKey1 | base64 -w0
      access-key:  dmVyeVNlY3JldEtleTE= # echo -n verySecretKey1 | base64 -w0
    —
    
  2. Add a BackupRepositoryManager custom resource to use these credentials and apply the new resource to the org admin cluster. Backup repositories are cluster-scoped:

    apiVersion: backup.gdc.goog/v1
    kind: BackupRepositoryManager
    metadata:
      name: backup-repository-gcs
    spec:
      readWriteCluster:
        name: user-1-user
        namespace: user-1-user-cluster
      backupRepositorySpec:
        secretReference:
          namespace: "gcs-secret-ns"
          name: "gcs-secret"
        endpoint: "http://storage.googleapis.com"
        type: "S3"
        s3Options:
          bucket: "bucket-name"
          region: "us-east-1"
          forcePathStyle: true
        importPolicy: "ReadWrite"
    

    This example includes the following values:

    Value Description
    readWriteCluster The cluster where the backup repository is created as readWrite.
    readOnlyClusters List of clusters where the backup repository is created as readOnly.
    secretReference A NamespacedName referencing the secret that contains access credentials for the endpoint.
    endpoint The fully-qualified domain name for the storage system.
    type The type of backup repository. Only the type of S3 is supported.
    s3Options The configuration for the S3 endpoint. This is required if the type is S3.
    • bucket: the name of the bucket.
    • region: the region of the given endpoint. The region is storage system specific.
    • forcePathStyle: this option decides whether to force path style URLs for objects.
    importPolicy Set to one of the following:
    • ReadWrite: This repository can be used to schedule or create backups, backup plans, and restores.
    • ReadOnly: This repository can only be used to import and view backups. No new backups or resources can be created in this repository, but restores can use and reference read-only backups for restoration. There is no restriction on how often a backup repository can be used as ReadOnly.

The BackupRepositoryManager propagates the secret into the user cluster and creates a BackupRepository resource in the user cluster.

Deactivate a backup repository

To get the permissions that you need to deactivate a backup repository, ask your Organization IAM Admin to grant you the Backup Repository Admin (backup-repository-admin) role.

Deactivate a backup repository using the GDC console:

  1. Sign in to the GDC console.
  2. In the navigation menu, click Backup for Clusters.
  3. Click the Repos tab.
  4. Click the name of the backup repository that you want to deactivate.
  5. Click the Deactivate Repository button.
  6. Enter the name of the backup repository into the text field.
  7. Click the Deactivate button to confirm the deletion of the backup repository.

Reactivate a backup repository

Reactivate a backup repository using the GDC console:

  1. Sign in to the GDC console.
  2. In the navigation menu, click Backup for Clusters.
  3. Click the Repos tab.
  4. Click the name of the backup repository that you want to reactivate.
  5. Click the Activate Repository button.
  6. From the Main cluster (read/write) dropdown menu, select the cluster that contains the repository you want to reactivate.

  7. Click the Activate button to confirm the reactivation of the backup repository.

Backup repository import policies

All clusters must have at least one ReadWrite repository to successfully use Backup and Restore features. ReadOnly repositories are optional, have no limit, and are used to gain visibility into other cluster backups for cross-cluster restores.

ReadOnly repositories cannot be used as storage locations for additional backups or for backup plans within the cluster they were imported.

Importing a repository as ReadWrite claims the repository for that cluster, preventing other clusters from importing the same repository as ReadWrite. After importing a ReadWrite repository, all records of previous backups, backup plans, and restores in that repository are imported into the target cluster as local custom resources.

Importing a repository as ReadOnly does not claim the repository, it only imports the backups, backup plans, restores, and restore plans. Backup plans in read-only repositories do not schedule backups, they exist to provide visibility into what backup plans exist in the cluster you are importing from. Removing a ReadOnly repository cleans up any imported resources from the cluster and has no effect on the resources in the storage location as no write operations occur to object storage for read-only repositories.

When a ReadWrite repository is removed from the cluster:

  • All local custom resources associated with that repository, such as backups and restores, are removed from the current cluster.
  • That cluster's claim on the repository is removed, allowing the repository to be used as ReadWrite by another cluster. However, these resources are not removed from the storage endpoint.