Supported PV types

CloudCasa Pro backups currently offer support for the persistent volume types listed below. When performing CloudCasa Pro restores from copy backups, any valid StorageClass that supports dynamic provisioning may be specified.

CSI

CloudCasa utilizes the Volume Snapshot API of the CSI driver to take snapshots of CSI PVs during backup. Note that for copy backups, the snapshot is used as the source of the backup. All storage classes using CSI drivers that properly support the snapshot API are supported, with the limitations or caveats noted below.

Note that CloudCasa requires the “v1” version of the volume snapshot CRDs. It is important to have all required CSI components (such as the CRDs and the external snapshotter) properly installed, as otherwise snapshot requests may fail.

AWS Elastic Block Store: Note that if EBS volumes are configured using CSI, they will be treated as any other CSI volumes. But it is also possible to configure EBS PVs using the “awsElasticBlockStore” provisioner. In order to snapshot such PVs, you need to add the corresponding AWS account to CloudCasa (See Cloud Accounts).

AzureDisk: Similar to EBS volumes, it is recommended to provision Azure Disk volumes using CSI. If for any reason they are configured with the provisioner “kubernetes.io/azure-disk”, CloudCasa can still snapshot the volumes but the user needs to create a Kubernetes “secret” in the cluster. For more details, contact CloudCasa support.

Google Persistent Disk

As with other cloud storage, it is highly recommended to use the CSI driver to provision Google Persistent Disk type PVs. But even if CSI is not used, CloudCasa can support GPD snapshots and backups with some additional configuration.

The recommended way to support non-CSI GPD PVs for GKE is to simply configure your GCP accounts in CloudCasa (see Adding a cloud account for Google Cloud Platform (GCP)). Automatic GPD support is then made available via an option in the GCP Deployment Template, since it requires additional permissions.

A manual configuration method for supporting non-CSI GPD PVs is also available. It requires the administrator to configure Kubernetes secrets in the cluster. For more details, contact CloudCasa support.

AWS Elastic File System (EFS) CSI: The EFS CSI driver does not support snapshots, so CloudCasa backs up data on EFS volumes directly from the live volume. Caveats are the same as for NFS volumes (see below).

AzureFile (CSI)

The CSI driver for “AzureFile” PVs does support snapshot functionality and CloudCasa utilizes it to take snapshots. However, the CSI driver does NOT support automatic restores from snapshots for clusters with version 1.28 or less. Instead, one normally needs to perform the restore in the Azure portal or using the Azure CLI, which is obviously tedious and error prone. So CloudCasa supports automatic restores from AzureFile CSI snapshots by natively integrating with the Azure APIs. Note that clusters with version 1.29 or higher will have the CSI driver that supports automatic restores from snapshots and CloudCasa will utilize this functionality.

Requirements:

Ensure that the StorageClass used to provision the volumes has reclaimPolicy set to Retain.
For statically provisioned volumes, ensure that the StorageClass has the storageAccount and resourceGroup parameters set.

Limitations:

#. CloudCasa attempts to restore data from file share snapshots using credentials stored in the backed-up secret. If the credentials change, the files will not be restored. Note that this issue is only present with snapshot restores. Restores from copy backups does not have this limitation.

Google Filestore (CSI): When Google Filestore volumes are configured with CSI, CloudCasa has complete support for snapshot/copy backups and restores.

Longhorn (CSI)

It is recommended to use Longhorn version 1.3 or later, since earlier versions incorrectly interpreted CSI snapshot creation requests.

When mounting a snapshot of a Longhorn volume, there may be a long delay since Longhorn performs a copy operation before completing the mount. Since CloudCasa, by default, always backs up from a snapshot when possible to maintain crash consistency, you may need to increase the Data mover pod timeout setting in the Advanced options section of your backup definition so that this delay doesn’t cause copy backups to fail. Alternatively, you can tell CloudCasa to back up data directly from the live PV instead of creating a snapshot first by setting the Copy from live Longhorn PVs option in the Advanced options section. If you use this option, you should consider using App Hooks to assure application consistency. Note that this paragraph applies only to copy backups (i.e. those with Snapshot & Copy selected), not to snapshot only backups.

NFS

NFS type PVs don’t support snapshots, so they can only be part of copy backups. Data is read by attaching the NFS PVCs to CloudCasa’s data mover pod.

Since data is backed up directly from the active NFS volumes rather than from snapshots, you should consider using application hooks (See App Hooks) to quiesce your application if locked or potentially inconsistent files are a concern. Also note that application hooks for NFS volumes may be executed at a different time than hooks for other PVs in the same application. This is only a potential issue for applications that use both NFS and non-NFS PVs and require cross-PV consistency (This limitation will be addressed in a future release).

Note that NFS volumes can mount shares from many different types of NFS servers, including cloud provider file storage such as Google filestore , Azure Files, and AWS’s EFS. In all these cases, the backup follows similar logic as described above.

Block Mode PVs: CloudCasa also offers backup and restore support for block mode PVs (i.e. those with volumeMode set to “Block”). From the user’s perspective, everything should work the same as for PVs with volume mode Filesystem.

Unsupported PV Types

The following PV types are known to currently not be supported by CloudCasa.

Local volumes: PVs using local storage (i.e. storage classes using “provisioner: kubernetes.io/no-provisioner”).
hostPath volumes: These volumes expose the underlying host filesystem and typically do not need to be backed up.
emptyDir volumes: These volumes are intended to be used for ephemeral data only and typically do not need to be backed up.
volumes using the Azure Blob CSI driver: These include any storage classes using the “blob.csi.azure.com” provisioner.

If you require support for an unsupported type of PV or have questions about PV support, contact CloudCasa support.