Overview

CloudCasa is a data protection and mobility solution for Kubernetes and cloud native applications. It was originally developed as a SaaS-only offering, but it is now also available as a self-hosted option which can be installed on-prem or in customer cloud environments.

At a high level, a CloudCasa self-hosted system consists of a server, a database, agents installed on each client cluster, and external S3-compatible or Azure object storage used to store the backup data.

Server

All CloudCasa service components, with the exception of the database, are deployed in a single namespace on a Kubernetes cluster, usually “cloudcasa-server”.

Database

All of the catalog data is stored in a MongoDB database. By default, we install MongoDB in a separate namespace called “cloudcasa-mongo”. Data will be stored in a 16 GB PVC created using the storage class configured at install time. You can optionally use your own MongoDB (or compatible) database instance by configuring its URI at install time.

Agent

The CloudCasa agent runs on each client cluster to perform backup and restore operations.

When you register a client cluster via the UI, you will see a “kubectl apply” command for installing the agent, which will be installed in the namespace “cloudcasa-io”. When the agent comes up, it connects to the CloudCasa service and you will see cluster state marked as “ACTIVE”. Anytime there is an issue with either the connection or the agent itself, the cluster state will change to “PENDING”.

Network Flow

Please see https://docs.cloudcasa.io/help/reference-network.html for more details.

Here are some things to note:

  • All agents connect to the CloudCasa server on port 443 (using the IP of the cluster service that is exposed to outside). This connection needs to be active all the time. Only control plane traffic travels over on this connection.

  • For backups and restores, the agent connects directly to the storage. For example, if AWS S3 is being used, the agent connects directly to S3 to read and write the data. Data traffic is not routed through the CloudCasa server.

  • The UI communicates with the CloudCasa server using a REST API.

  • When an agent is installed on a cluster, kubectl connects to the CloudCasa server and does a GET to fetch the agent YAML.

There is no connection whatsoever from a self-hosted installation of CloudCasa to the CloudCasa SaaS service or vice versa.