Supported PV types

CloudCasa Pro currently supports the following types of persistent volumes:


CloudCasa utilizes the Volume Snapshot API of the CSI driver to take snapshots of PVs. Note that CloudCasa requires “v1” version of the volume snapshot CRDs. It is important to install all required CSI components (such as external snapshotter) as otherwise, snapshot requests would fail.

For copy backups, the snapshot is used as the source of the backup.

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


Similar to EBS volumes, it is recommended to provision Azure Disk volumes using CSI. If for any reason they are configured with the provisioner “”, 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.

AzureFile (CSI)

The CSI driver for “AzureFile” PVs does support snapshot functionality and CloudCasa utilizes it to take snapshots. But the CSI driver does not support automatic restores from snapshots. 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 the automatic restore feature requires subscription to a premium service plan.


  1. Ensure that the StorageClass used to provision the volumes has reclaimPolicy set to Retain.

  2. For statically provisioned volumes, ensure that the StorageClass has the storageAccount and resourceGroup parameters set.


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

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