Supported PV types

CloudCasa supports two different data protection methods for persistent volumes: “Snapshot only”, and “Backup to object storage”. Further, backing up to object storage can be done using three different methods: “Read data from snapshot”, “Read data from PVC”, and “Read data from underlying host volume”. Not all types of PVs support all backup methods.

CloudCasa Pro backups currently offer support for the persistent volume types listed below. When performing CloudCasa Pro restores from object storage, 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 AWS Elastic Block Store (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).

Azure Disk

Similar to EBS volumes, it is recommended to provision AzureDisk 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)

The AWS Elastic File System (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 Azure Files CSI driver that supports automatic restores from snapshots and CloudCasa will utilize this functionality. However, you may still want to use CloudCasa method in some cases, due to some limitations with the CSI driver method. More information regarding requirements and limitations for both methods is given below.

  • CloudCasa Method

    • 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.

  • CSI Driver Method

    • Requirements

      • Ensure that the AKS agentpool managed identity has permission to list keys for storage accounts created in the node resource group. You can assign the “Reader and Data Access” role to the agentpool managed identity.

    • Limitations

      • The CSI Driver method does not work with storage accounts with restricted access, i.e. storage accounts that can only be accessed via private endpoints or storage accounts that can only be accessed via a list of VNets.

On cluster versions 1.29 or higher, CloudCasa will use CSI driver to create PVCs from snapshots (to be used as source for the backup) by default. On cluster versions 1.28 and lower, CloudCasa method will be used for the same purpose. But you can select one or the other method explicitly using the option Azure Files Snapshot Restore Method available in “Advanced options” while defining backups.

Google Filestore (CSI)

When Google Filestore (CSI) 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.

Rancher Local Path Provisioner

Volumes using the Rancher Local Path Provisioner (i.e. provisioner “rancher.io/local-path”) are supported by CloudCasa for direct backups only. The Local Path Provisioner does not support snapshots.

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 the built-in local volume feature in Kubernetes (i.e. storage classes using “provisioner: kubernetes.io/no-provisioner”). Note that volumes using the Rancher Local Path Provisioner are supported. See above.

hostPath volumes

These volumes expose the underlying host filesystem and normally do not need to be backed up.

emptyDir volumes

These volumes are intended to be used for ephemeral data only and normally 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.