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.
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.
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.
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.
No. Currently, there are no limits on worker nodes per cluster. Our free service allows registering clusters with any number of worker nodes.
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.
There is no cost to using the CloudCasa service today.
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 to provide features that would be beneficial to enterprise customers. I wouldn't limit this to "enterprise customers", also features should include retention policy, number of clusters etc.
We are pretty active in the CloudCasa Forums and are happy to hear from you!
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.
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.
We view your use of our service as a compliment. We do however adopt a fair use policy and reserve our right to modify it without notice, as necessary.
Requirements and Support Questions
- 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.
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.
- 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.
The ClusterAdmin role is required.
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
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
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:
volumeAttributes: storage.kubernetes.io/csiProvisionerIdentity: 1604419926974-8081-hostpath.csi.k8s.io
Backup and Restore Questions
Yes! Your data is compressed.
Yes! Your data is encrypted both over the network and at rest.
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.
This is currently restricted in the UI.
Tags are used as resource identifiers within CloudCasa's database. Labels are typically used as identifiers in your Kubernetes clusters.
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.
Yes! CloudCasa supports adding a prefix and/or suffix to the restored namespace.
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.
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.
- 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.
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.
After a cluster is unregistered, its recovery points are currently unusable even if the same cluster name is reused.
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.