Storage

The Storage page allows you to define storage targets for backups. From the menu bar, go to Configuration > Storage. On this page, you can view a list of your defined storage endpoints and edit or delete them. For CloudCasa Pro service, it is only necessary to define storage endpoints here if you with to use user-supplied storage. For CloudCasa for Velero service, at least one separate storage location must be defined for each cluster running Velero.

Several different types of storage are supported.

Storage For CloudCasa Pro backups

  • CloudCasa Managed Storage - Available in various regions of AWS and Azure

  • User-supplied Storage - Any S3-compatible or Azure object storage.

For CloudCasa Pro backups, storage locations are global and can be shared across multiple clusters. Many clusters can back up to the same storage and CloudCasa automatically handles separation of data between these clusters.

You have a choice of where to send backup data with CloudCasa. You can use CloudCasa’s secure cloud storage, which is included in the paid service plans, or you can use your own object storage. If you wish to use your own object storage, you must define the endpoints for it here. Note that configuring storage here is not required to use CloudCasa Pro.

CloudCasa supports most types of object storage that are compatible with the Amazon S3 API or Microsoft Azure Blob storage as user-supplied storage.

A global “Default storage” location for your organization can be set at the top of the page. The defaults are inherited by clusters and backup jobs unless overridden. A change in Storage target will lead to a new full backup.

Storage For Velero backups

  • BackupStorageLocations - Any compatible S3 Storage

  • VolumeSnapshotLocations - For offloading snapshot data

For Velero, one must create a separate BSL for each cluster. Sharing the same BSL across multiple clusters could lead to data loss. One can use the same S3 bucket as different BSLs provided the user sets up unique prefix during the configuration. CloudCasa for Velero will automatically detect duplicate BSLs and alert users about potential data loss.

All inventoried BSLs are displayed under Configuration > Storage > Backup Storage

BSL specifications include:

Cluster

Name of the Cluster the BSL is configured in.’

Bucket Name

Name of the S3 Bucket

Prefix

A Prefix is set when the same bucket is shared across multiple clusters. The BucketName+Prefix combination for BSLs must be unique, unless a BSL is being mapped in ReadOnly AccessMode.

AccessMode

Read/Write implies the BSL is configured for backup and recovery on a cluster. ReadOnly implies the BSL is mapped for recovery purposes alone on a cluster. If CloudCasa for Velero identifies identical BSLs mapped in more than one cluster as Read/Write, it will alert users about potential data loss.

Status

Velero continually verifies and validates BSLs and sets the “Available” state to No if there are access or connectivity issues to the BSL. Validation Frequency is 1 min by default.

CloudCasa for Velero supports most types of object storage that are compatible with the Amazon S3 API or Microsoft Azure Blob storage as BSL. S3 Storage from AWS, Azure and GCP have been explicitly tested and certified, but it is reasonably safe to assume that if your BSL works with Velero, it will work with CloudCasa for Velero.

Adding Velero BackupStorageLocations

On the Storage page, select the Backup storage tab and click Add Storage +.

Select “Velero” as the Storage Type. You must specify the following:

Cluster

Name of the Cluster the BSL is configured in.

AccessMode

Read/Write implies the BSL is configured for backup and recovery on a cluster. ReadOnly implies the BSL is mapped for recovery purposes alone on a cluster. If CloudCasa for Velero identifies identical BSLs mapped in more than one cluster as Read/Write, it will alert users about potential data loss.

IsDefault

Velero allows you to set a BSL as the default storage for backups. If multiple BSLs are defined as default in the same cluster, Velero random rotates among these default storage options. Default BSL can be overridden by the Backup Specifications.

Disable TLS Certificate Validation

Disables Transport Layer Security for backups to this BSL. Not Recommended.

Provider Type

Available options are AWS/S3 Compatible, Azure Blob Storage and GCP/GCS Compatible Storage. For On-premises or other cloud storage targets, most are compatible with AWS S3 and select the option to proceed with configuration. For each storage type, different options are presented to configure the BSL.

Adding Amazon S3 or S3 Compatible Storage

You can add S3 Storage Endpoint through two authentication methods: AWS IAM Roles for Service Accounts(IRSA) and AWS credentials that are AccessKey/SecretKey based. IRSA method is recommended for better auditability and role management, but AccessKey/SecretKey method is supported by most object storage vendors. Spec for AWS BSL is available here.

Adding Azure Blob Storage

You can add Azure Blob Storage as a backup target through two authentication methods: Azure Service Principal and Azure Storage Account Access Key. The Service Principal method is recommended for better auditability and role management. If using Access Key, it is recommended to rotate and regenerate keys regularly manually or through a Key Vault. Detailed Spec for Azure BSL is available here.

  • For both methods, you will need: Resource Group Name and Storage Account Name

  • For Service Principal authentication, you will also need: Subscription ID, Tenant ID, Client ID, Client Secret

Adding Google Cloud Storage

You can add Google Cloud Storage (GCS) or GCS-compatible storage through two authentication methods: Google Service Account Key and Google Workload Identity. Google Workload identity is the recommended method. Detailed Spec for Google BSL is available here.

  • For both authentication methods, you will need: Google Access ID

  • For Google Service Account Key method, you will need: Type, Project ID, Private Key, Client Email, Client ID, Auth URI, Token URI, Auth Provider X509 Certificate URL, Client X509 Cert URL. You can import a JSON file with these values if performing this action repeatedly for each cluster.

  • For Google Workload Identity method, you will need: Kubernetes Service Account Namespace, Kubernetes Service Account Name, Service Account.

BSL Name

Name of the BSL. It is generally recommended you follow a naming convention that includes the cluster name, provider, region in the BSL in order to easily associate them during selection or in case of DR. BSL Name must be in lowercase and the UI will convert automatically.

Bucket Name

Name of the S3 Bucket

Prefix

A Prefix is set when the same bucket is shared across multiple clusters. The BucketName+Prefix combination for BSLs must be unique, unless a BSL is being mapped in ReadOnly AccessMode for recovery purpose.

Adding Velero Volume Snapshot Locations

A volume snapshot location is the location in which to store volume snapshots created for a backup. Velero can be configured to take snapshots of volumes from multiple providers. Velero also allows you to configure multiple possible VolumeSnapshotLocation per provider, although you can only select one location per provider at backup time.

In the Storage page, select the Snapshot Storage ** tab and click **Add storage +. You must specify the following:

Cluster

Name of the Cluster the VSL should be configured in.

Provider Type

Available options are AWS/S3 Storage, Azure Blob Storage and GCP/GCS Storage. For each storage type, different options are presented to configure the VSL.

AWS VSL:

In order to configure your VSL in AWS, you must select the Region you want to store the snapshots in, VSL Profile Name (e.g. Default), and credentials through Access/Secret Key or IRSA. Spec for AWS VSL is available here.

Azure VSL:

In order to configure your VSL in Azure, you must provide the Resource Group Name, Subscription ID, and the details for Authentication either through Azure Service Principal or Azure Storage Account Access Key. Azure supports selection of snapshot type (Full or Incremental). Full snapshot is the default. Spec for Azure VSL is available here.

GCP VSL

In order to configure your VSL in GCP, you must provide the Region and Project Name. Spec for GCP VSL is available here.

Adding Amazon S3 storage for CloudCasa Pro

Take the following steps to register the Amazon S3 or S3-compatible object storage with CloudCasa:

  1. In the Storage page, select the Backup storage tab and click Add storage +.

  2. In the Add storage pane, enter the following fields:

    Name

    Display name for the Storage location.

    Provider type: S3

    Select S3 to register the Amazon S3 or compatible storage.

    Bucket name

    Enter the bucket name of the S3 storage.

    Access key

    Enter the access key of the S3 storage.

    Secret key

    Enter the secret key of the S3 storage.

    Endpoint

    Enter the regional endpoint URL of the S3 storage. It usually is of the type “https:://service-code.region-code.provider.com”. E.g: https://s3.ap-south-1.amazonaws.com, https://s3.eu-west-2.wasabisys.com

    Region:

    Enter the region under which the Amazon S3 bucket is created. ( This is not applicable for non-Amazon buckets )

    Is your storage isolated/restricted from Internet access?

    Choose Yes if your storage is not reachable via the public Internet.

    Proxy cluster

    If the storage is marked as isolated, you must choose a cluster with an active CloudCasa agent which will be responsible for performing management operations on the storage. The storage must be reachable from this cluster.

    Disable TLS certificate validation

    It is recommended to not enable this setting. Enabling it allows connections to the storage endpoint even if the server certificate is self-signed or expired, or if the domain name does not match the host.

    1. Click Save.

Adding Microsoft Azure Blob storage for CloudCasa Pro

Take the following steps to register a Microsoft Azure Blob storage endpoint with CloudCasa:

For required permissions see Permissions required for accessing Azure Blob Storage.

  1. In the Storage page, select the Backup storage tab and click Add storage +.

  2. In the Add storage pane, enter the following information:

    Name

    Display name for the Storage location.

    Provider type: Azure

    Select Azure to register the Microsoft Azure Blob storage.

    Subscription ID

    Enter the subscription ID of the Microsoft Azure plan that you have purchased.

    Client ID

    Enter the unique Client (Application) ID assigned by Microsoft Azure when the application was registered.

    Client Secret

    Enter a valid client secret of the Service Principal.

    Tenant ID

    Enter the tenant ID associated with the Microsoft Azure subscription.

    Resource Group Name

    Enter the resource group name that will be used to hold all resources for the storage.

    Storage Account Name

    Enter the name of the storage account created under the same resource group.

    Region

    Enter region name associated with the resource group.

    Is your storage isolated/restricted from Internet access?

    Choose Yes if your storage is not reachable via the public Internet.

    Proxy cluster

    If the storage is marked as isolated, you must choose a cluster with an active CloudCasa agent which will be responsible for performing management operations on the storage. The storage must be reachable from this cluster.

    Disable TLS certificate validation

    It is recommended to not enable this setting. Enabling it allows connections to the storage endpoint even if the server certificate is self-signed or expired, or if the domain name does not match the host.

  3. Click Save.