CloudCasa is a cloud native Software-as-a-Service (SaaS) solution for backup of Kubernetes clusters and cloud databases. CloudCasa offers a free service tier that allows you to backup your Kubernetes metadata and resource data to our secure storage, and orchestrate snapshots of Container Storage Interface (CSI) and (for EKS) AWS EBS persistent volumes (PVs) on local storage. It also offers creation and management of AWS RDS database snapshots and snapshot copies.
Future paid service tiers will offer additional services, such as backup of Kubernetes PVs to our secure storage. For a limited time, free tier users can use this "Copy PV to CloudCasa" service to protect up to 5TB of persistent volumes at no charge.
Just create an account and log in to the service at home.cloudcasa.io/signup. You will not need to set up any infrastructure or install any software other than our Kubernetes agent. After creating an account, you can register your Kubernetes clusters and RDS databases. For protecting Kubernetes, CloudCasa will direct you to run a kubectl command on each cluster to install the agent and initiate a connection to the CloudCasa service. For protecting RDS databases, you will need to configure your AWS account(s). After this setup is done, you will be able to protect your clusters and databases using our 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 Forum if you have any questions about your environment.
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 the 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. No payment information is required to sign up. We will soon be introducing a paid service tier with additional features, but we plan for the features currently offered in the free service (except for the preview of PV copy to CloudCasa) to remain free!
Correct! There is no cost to use the features that are available today. We will support our efforts with paid plans in the future to provide features that would be beneficial to enterprise customers.
We actively monitor the CloudCasa Forum and are happy to hear from you! You can also contact us via email at firstname.lastname@example.org.
The default is once an hour, but there are ways to get around it. For more information, reach out to us through the CloudCasa Forum.
Our free service limits data retention to 30 days. If this precludes you from benefiting from our service, let us know through the CloudCasa Forum.
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.
No. However, since we have just introduced this feature, we are making it available to all users for free for a limited time. So you can now backup up to 5TB of persistent volumes by selecting "Snapshot and copy to CloudCasa" in your backup definitions.
The limit is based on how much PV data you are protecting, not on how much data you back up. The sum of the allocated sizes of all PVs that you protect with the "Snapshot and copy to CloudCasa" feature must be less than 5TB. If you need to back up more data during the period, contact us at email@example.com.
We expect to end this promotion to September, 2021.
When the promotion ends, if you choose to not subscribe to our premium service tier you will still be able to run “Snapshot only” backups for free. Existing backups jobs will switch from "Snapshot and copy to CloudCasa" to "Snapshot only". Existing recovery points will remain available for restores based on their retention period.
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 and configured.
- 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 "Include persistent volumes", 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. By default, all persistent volumes (PVs) that support the CSI snapshot API and AWS EBS PVs will be snapshotted on local storage, but not transferred to the cloud. If "Snapshot and copy to CloudCasa" is selected, the PV data will be 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) and AWS EBS PVs. This option can be selected in the user interface when defining a backup. Non-CSI volumes other than AWS EBS volumes are not yet supported. For a limited time, we are also offering free tier customers the ability to copy PVs to CloudCasa's secure storage for additional protection. This additional service will become part of future paid offering.
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 agent yaml file of your original cluster. You can obtain this from the Setup tab in the UI. Finally, run a restore. If you will be restoring PVs from snapshots, this requires that any CSI driver must be installed with the same name as the source.
See the CloudCasa Kubernetes Restore Guide for more details.
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 it is know that a job will fail, its execution will be skipped. Common reasons for skipping a job include the cluster having no active connection, and another instance of the same job already running.
A job will also be marked as skipped if scheduling of it has been paused through the UI.
You can set backup destinations in three different ways.
- The default backup destination for your entire account can be set under the Preferences tab.
- A per-cluster default backup destination can be set under Advanced options in the Edit cluster window.
- The backup destination for an individual backup job can be set under advanced settings in the Edit backup window.
The per-cluster setting will supersede the account-wide default, and the backup job setting will supersede both.
Amazon AWS and 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”.
A cross-account role is used to grant the CloudCasa service permission to manage your RDS backups and manage snapshots of EKS EBS PVs. For convenience, this is created using a CloudFormation stack, and it can be removed by removing the stack. The stack lets the user choose whether to include permissions for RDS backups, for EKS EBS PV backups, or both. 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:
For RDS data protection:
For EKS EBS PV protection:
- When a cluster is unregistered from the CloudCasa user interface, existing backups (snapshots or copies) 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.
If you installed your agent by using the kubectl command provided in the CloudCasa UI, you can upgrade in the following way:
1.Run "kubectl delete namespace cloudcasa-io" to remove the existing agent.
2. Go to the Protection/Clusters tab in the UI and select your cluster. The kubectl command to install the new agent will be displayed. It will look something like "kubectl apply -f https://api.cloudcasa.io/kubeclusteragents..." but will be unique for each cluster. Just run this command and you're done!
If you installed the agent using a Helm chart or through a marketplace such as Rancher or Digital Ocean, you will need to follow the update instructions specific to your install method. See the appropriate item below
The updated agent is not yet available. Please check back in a few days.
The updated agent is not yet available. Please check back in a few days.
Sometimes new features we introduce require new AWS permissions, which in turn requires launching a new version of the CloudFormation stack.
Click on the Protection/Accounts tab. There will be a "!" icon next to each account that needs a CloudFormation stack update. Select each account. Above the account details you will see the message "Active but requires CloudFormation stack update" with an "Update stack" link next to it. Clicking on the link will take you to the AWS CloudFormation console where the stack will launch once you have logged in. This is the same process you used when you initially configured your account in CloudCasa.
Our AWS CloudFormation stack creates a cross-account role that grants CloudCasa the permissions it needs, and only the permissions it needs, to protect your data. Currently these permissions can be broken down into two sets. The first is permissions required to backup and restore RDS databases. The second is permissions required to snapshot EKS EBS PVs.
Since you may not wish to grant CloudCasa permissions required for a feature you aren't using, the CloudFormation stack launch page lets you choose which permission sets to include: RDS, EBSVolumeSnapshot, or both. Both will be enabled by default.
If you wish to change your selection later, you can so so by re-launching the CloudFormation stack.