General Questions

What is CloudCasa?

CloudCasa is a Kubernetes (K8s) native and cloud native Software-as-a-Service (SaaS) solution that supports backup of Kubernetes clusters. One can register an account and login to the service at https://www.cloudcasa.io. CloudCasa offers a free service to backup your metadata and resources data to S3 and orchestrate Container Storage Interface (CSI) snapshots on your Kubernetes clusters. 

What do I need to set up to use CloudCasa?

Register an account and login to the service at https://www.cloudcasa.io. You do not have to set up a backup server or storage for backing up with CloudCasa. After creating an account, you can register your clusters. CloudCasa will direct you to run a kubectl command on each cluster to initiate connection to the CloudCasa service. After the connection is established with CloudCasa, you can configure backups to be sent to CloudCasa storage as well as orchestrate CSI snapshots through flexible scheduling policies. 

What Kubernetes distributions are supported by CloudCasa?

CloudCasa is designed to protect any Kubernetes distribution, installed on-premises or in the cloud. CloudCasa is designed to work with popular K8s distributions such as Red Hat OpenShift, Suse Rancher, and VMware Tanzu, and also with cloud-based managed Kubernetes services such as EKS, AKS, and GKE. Almost all flavors and recent versions of Kubernetes are supported. A full list of tested platforms are available in the Requirements and Support section of this FAQ. Additionally, you may reach out to us through our CloudCasa Forums if you have any questions about your environment.

How does CloudCasa differ from KubeDR?

KubeDR is an open source offering, also created by the team at Catalogic Software, that implements data protection for Kubernetes cluster data stored in etcd with optional support for certificates. We welcome your participation in ongoing improvement and maintenance in this open source project. CloudCasa is a service offering that caters to some overlapping use cases, but delivers additional protection for CSI persistent volumes (PVs) and offers free secure storage for your resource data.


Service Questions

Is there a limit on the number of worker nodes I can protect?

No. Currently, there are no limits on worker nodes per cluster. Our free service allows registering clusters with any number of worker nodes.

Is there a limit to the number of clusters for an account?

No. Currently, there are no limits on number of clusters per user. Our free service allows registering any number of clusters with any number of worker nodes.

Is there a cost to use CloudCasa?

There is no cost to using the CloudCasa service today.

Seriously, is there really no cost to use CloudCasa?

Correct! There is no cost to use the features that are available today. We may support our efforts with paid plans in the future to provide features that would be beneficial to enterprise customers.

How do I obtain support for CloudCasa?

We are pretty active in the CloudCasa Forums and are happy to hear from you!

What is the maximum frequency supported for backups?

The default is once an hour, but there are ways to get around it. For more information, reach out to us through the CloudCasa Forums.

What is the maximum retention?

Our free service limits data retention to 30 days. If this precludes you from benefiting from our service, let us know through the CloudCasa Forums.

How do you prevent abuse of a free service at scale?

While use of CloudCasa is free, we do have a Fair Use Policy that reserves our right to prevent abuse of our complimentary services. We hope that a good experience with CloudCasa will encourage customers to look at our other services and product offerings that address their more complex needs.


Requirements and Support Questions

What are the requirements for CloudCasa?
  • The registered cluster must be version 1.13 or higher for protecting resource data. In order to leverage CSI snapshots, the registered cluster must be version 1.17 or higher. The CSI driver must support volume snapshots at the v1beta1 API level. For a list of vendors that support CSI snapshots, please see: https://kubernetes-csi.github.io/docs/drivers.html.
  • kubectl must be installed locally.
  • You will need cluster administrative access to install CloudCasa's lightweight agent on your cluster. While registering your cluster in the user interface (UI), each cluster will be given a unique YAML file to be applied to your cluster. 
  • Network access from your cluster outgoing to the CloudCasa service (agent.cloudcasa.io) on port 443.
What versions of Kubernetes are supported?

The registered cluster must be version 1.13 or higher for protecting resource data. In order to leverage CSI snapshots, the registered cluster must be version 1.17 or higher. The CSI driver must support volume snapshots at the v1beta1 API level. For a list of vendors that support CSI snapshots, please see: https://kubernetes-csi.github.io/docs/drivers.html.

Are there specific ports that must be opened for CloudCasa to operate?
  • CloudCasa relies on Cloud Native Computing Foundation (CNCF)'s gRPC for its communication. Your cluster should allow an outgoing TCP connection to the CloudCasa service (agent.cloudcasa.io) on port 443. This typically doesn't require any changes to your network firewall and there is no need to open network ports for incoming connections.
  • For accessing our home page, https://home.cloudcasa.io service must be reachable from your favorite web-browser.
What permissions are required for CloudCasa agent to operate?

The ClusterAdmin role is required.

How do I verify that my CSI snapshot configuration is properly configured?

To verify that your CSI snapshot configuration is properly configured, run kubectl -n <namespace> get pvc to observe the storageclass used to define the PVC of interest.


$ kubectl -n mongo get pvc

mongo-vol-mongo-0 Bound pvc-bbc599d1-f988-4178-99a3-545bce997b58 4Gi RWO csi-hostpath-sc 49m

You can also find more details about this PV by running the following command:

$ kubectl get pv <pvc-name> -o yaml


$ kubectl get pv pvc-bbc599d1-f988-4178-99a3-545bce997b58 -o yaml

The CSI section in the YAML file will appear similar to this:

driver: hostpath.csi.k8s.io
volumeAttributes: storage.kubernetes.io/csiProvisionerIdentity: 1604419926974-8081-hostpath.csi.k8s.io
volumeHandle: 29aca293-1e02-11eb-a7a7-0242ac120005

Backup and Restore Questions

What gets backed up when I select the whole cluster in CloudCasa?

With the default cluster backup settings of "Full Cluster" and "Enable PV snapshots", all namespaces and all cluster-scoped resources will be included in the backup. All resource data is automatically backed up to CloudCasa's secure cloud storage. All persistent volumes (PVs) that support the CSI snapshot API are snapshotted, but are not transferred to the cloud.

Is my data compressed?

Yes! Your data is compressed.

Is my resource data encrypted?

Yes! Your data is encrypted both over the network and at rest.

Will CloudCasa protect persistent volumes?

Yes! CloudCasa is able to snapshot CSI persistent volumes (PVs). This can be modified in the user interface (UI) while defining a backup. Non-CSI volumes are not supported.

Can I restore my data to a different cluster?

Yes. You can simply select an alternate cluster in the Restore dialog. However, you must take in to account the following restrictions:

  1. The target cluster must be registered with CloudCasa and in the ACTIVE state before a restore can be done.

2. For PVCs of type CSI:

Ensure that the CSI drivers that were deployed in the source cluster are deployed with the same configuration on the target cluster. This can be confirmed by listing the CSI drivers using the command:

$ kubectl get csidriver


Ensure that the CSI drivers in the target cluster have access to the storage snapshots that were taken during the backup of the source cluster. For Example, CSI drivers for EBS volumes require the associated IAM policies to be created, and the configmap with access credentials to be created in the cluster.

What are the different options for selecting cluster resources for backup?

The default setting when you first enter the “Add New Backup” wizard is to protect EVERYTHING. However, CloudCasa offers a variety of selection options to let you specify exactly what you want backed up, so it is important to understand how they work and interact. 

If the "Full Cluster" option is chosen, CloudCasa will back up all resources in the cluster, including all namespace-scoped and cluster-scoped resources.  

If the “Select Namespaces” option is chosen, only the selected namespaces will be backed up. Cluster-scoped resources will only be backed up if they are associated with selected namespace-scoped resources. 

If the “Select Labels” option is selected, only resources with the specified key-value labels will be backed up. If multiple key-value labels are specified, the relationship between them is logical AND, meaning ALL listed labels need to be present and their values need to match. For example, if “owner:bob” and “env:production” are specified, then only resources with BOTH the labels “owner:bob” AND “env:production” will be backed up. This filtering applies to both namespace-scoped and cluster-scoped resources.  

If “Select Namespaces” and “Select Labels” are BOTH selected, the filtering has a cumulative effect. Only resources that are both in one of the selected namespaces (or are associated with a resource that is, in the case of cluster-scoped resources) AND have the specified labels will be backed up.  

Remember that the filtering applies to persistent volume snapshots as well! 

What are tags and what are labels?

Tags are used as resource identifiers within CloudCasa's database. Labels are typically used as identifiers in your Kubernetes clusters.

My cluster is dead, how can I restore it?

First, install a new Kubernetes cluster. Next, apply the same agent file of your source cluster from the Setup tab in the UI. Finally, run a restore. This requires that any CSI driver must be installed with the same name as the source.

Can I restore to a different namespace?

Yes! CloudCasa supports adding a prefix and/or suffix to the restored namespace.

Can I delete policies?

Yes! To delete a policy, find it in the Backup Policies list under the Setup tab and click on the edit arrow for it. The Remove option is at the bottom left of the Edit dialog. However, the system won't allow you to delete a policy if it is currently referenced by a backup definition. You would need to edit your backup definitions and select alternate policies for them prior to deleting the policy.

Why would a backup job have the status "Skipped" in the activity window?

If a job can be predicted to fail, its execution will be skipped. Common reasons for skipping a job include when the registered clusters have no active connection and when another session of the same job is already active. 


Amazon RDS Questions

What Amazon RDS databases are supported by CloudCasa?

All Amazon RDS databases are supported, including Aurora.

Can CloudCasa support RDS databases in multiple accounts and regions?

Yes. Multiple AWS accounts can be associated with a single CloudCasa account, and RDS databases or clusters from multiple accounts and regions can be managed together.

Can CloudCasa copy a database snapshot to a different region?

Yes. When defining the backup, simply enable the “Copy to another region” option and select a region to copy to. You can choose to retain the initial snapshot or to remove it when the copy completes. The schedule and retention period for the copy will be determined by the copy policy you select.

Remember that that copying to other regions can take several hours to complete, and that RDS backup snapshots will be disabled until the copy is completed. This limitation is imposed by AWS, not by CloudCasa.

Can CloudCasa restore a database to a region different from the one it was backed up from?

Yes. However, right now you must have configured the backup to copy to the region you wish to restore to. You can also perform an ad-hoc copy to the region you want by defining an RDS backup with a remote copy, using the “run now” option, and selecting “copy only”.

Can the same policies be applied to both Kubernetes and Amazon RDS backups?

Yes. Policies defined in CloudCasa can be applied to both Kubernetes clusters and RDS databases, so you can have common policies for all parts of a given application or workload. Note, however, that policies user for RDS copies cannot have an hourly component. This is to prevent problems caused by AWS preventing new snapshots while a copy is in progress.

Why don’t I see recent RDS-related information in the UI?

Currently CloudCasa only queries AWS for updates related to RDS every 12 hours, so databases that you have recently added or automatic snapshots that were recently created may not appear in the UI. You can trigger a refresh manually by going to the Accounts tab under Protection, selecting each account that you are interested in, and clicking “Run inventory”.

What AWS permissions does the CloudCasa service require to manage RDS backups?
A cross-account role is used to grant the CloudCasa service permission to manage your RDS backups. For convenience, this is created using a CloudFormation stack, and it can be removed by removing the stack. A user with administrator permission is required in order to create the CloudFormation stack when initially linking your AWS account to your CloudCasa account, but the cross-account role that is used requires a much smaller set of permissions. The exact permissions used are the following:
  • iam:ListAccountAliases
  • rds:DescribeDBClusters
  • rds:CreateDBInstance
  • rds:DescribeDBInstances
  • rds:ModifyDBInstance
  • rds:CreateDBSnapshot
  • rds:DescribeDBSnapshots
  • rds:DeleteDBSnapshot
  • rds:DescribeDBSubnetGroups
  • rds:CreateDBClusterSnapshot
  • rds:DescribeDBClusterSnapshots
  • rds:DescribeDBInstanceAutomatedBackups
  • rds:DeleteDBClusterSnapshot
  • rds:RestoreDBInstanceFromDBSnapshot
  • rds:RestoreDBClusterFromSnapshot
  • rds:DescribeDBParameterGroups
  • rds:DescribeDBClusterParameterGroups
  • rds:DescribeOptionGroups
  • rds:RestoreDBInstanceToPointInTime
  • rds:RestoreDBClusterToPointInTime
  • rds:CopyDBSnapshot
  • rds:CopyDBClusterSnapshot
  • rds:AddTagsToResource ec2:DescribeRegions ec2:DescribeSecurityGroups


What happens when a cluster is deleted?
  • When a cluster is unregistered from the CloudCasa user interface (UI), backups are not automatically deleted. Backups are only deleted when their assigned retention period expires. A cluster cannot be unregistered if a backup job is pointing to it. You will need to delete the backup jobs referring to the cluster before unregistering the cluster.
How do I remove CloudCasa after the cluster resource is deleted from the UI?

If you no longer intend to use CloudCasa on a cluster, run the following commands in your cluster. 

kubectl delete namespace/cloudcasa-io clusterrolebinding/cloudcasa-io
kubectl delete crds -l component=kubeagent-backup-helper"

If the cluster is also unregistered in the user interface (UI), the recovery points are no longer usable.

If I delete a cluster after unregistering and then recreate the same cluster again using an identical name, am I able to restore existing backups to it?

After a cluster is unregistered, its recovery points are currently unusable even if the same cluster name is reused. 

I accidently ran the same registration command using the unique YAML file on two clusters?

In such cases, the last cluster that you register assumes the identity. Any cluster previously registered using the same registration YAML file can no longer communicate with CloudCasa service. If the current cluster is not the intended cluster, rerun the command in the intended cluster.  

submit a ticket

Didn't Find Your Question? Just Ask Us!

    CloudCasa Forum

    For more visit our Forum

    Be the First to Try It

    Signing up for our newsletter gives you early access to our Grand Opening!