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 provide features that would be beneficial to enterprise customers.
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.
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
- 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
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.
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.
Yes. You can simply select an alternate cluster in the Restore dialog. However, you must take in to account the following restrictions:
- 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.
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!
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.
Amazon RDS Questions
All Amazon RDS databases are supported, including Aurora.
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.
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.
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”.
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.
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”.
- rds:AddTagsToResource ec2:DescribeRegions ec2:DescribeSecurityGroups
- 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.