CloudCasa Pro Backup Guide

Step 1 - Create an Account

Point your favorite web browser to home.cloudcasa.io and create an account. No payment information is required for the Free service plan. Once you’ve signed in, you can invite other people to join your organization under Configuration/Users.

Step 2 - Configure your AWS, Azure, and GCP accounts (optional)

If some of your Kubernetes clusters are running in AWS, Azure, or GCP, we recommend adding your cloud accounts under Configuration/Cloud Accounts. This allows CloudCasa to auto-discover your EKS, AKS, and GKE clusters, back up EKS, AKS, and GKE cluster parameters, auto-create clusters on restore, and automatically back up non-CSI EBS volumes on EKS. For some configurations, it also gives you the option of auto-installing the agent.

See also

For more information on adding cloud accounts, see Cloud Accounts.

Step 3 - Add your clusters

If your clusters were auto-discovered, you’ll just need to find them in the Clusters list under your cloud account in Configuration/Cloud Accounts and click on the install icon for each one. If not, you can add them manually by clicking “Add cluster” under Clusters/Overview. Then enter your cluster name and description and click “Register cluster”. Either way, you will see a cluster ID and a kubectl command to run that will install a lightweight agent on the cluster. If you are installing via our Helm chart or via a partner marketplace instead, make a note of the Cluster ID and follow the instructions specific to your installation method. Once installed, the agent will connect and register itself with the CloudCasa service, completing the process.

Step 4 - Create a backup policy

A backup policy allows you to define when backups that use it will run, and for how long they will be retained. You can have multiple schedules with different retention times in one policy. For example, a policy may specify the creation of hourly backups that are retained for 7 days, and daily backups that are retained for 30 days. You can add or edit policies under Configuration/Policies. Add a new one, if you haven’t created one already, by clicking the “Add policy” button.

See also

For more information on policy creation, see Policies.

Step 5 - Define a backup

Go to the Clusters/Backups page and click “Define Backup”. The cluster backup wizard will open, which has several steps. First, select the cluster you wish to back up. In this case, this will be the cluster you just defined.

Next, choose what you wish to protect. Various options are available to select resources by namespace, resource type, or label, and to include or exclude persistent volumes. The default is to back up the full cluster including persistent volumes, and this is generally the safest option to start with. Next you must choose how to protect your persistent volumes. The options are “Snapshot only” or “Snapshot and copy”. The former will create only local snapshots of your PVs, while the later will create snapshots and then copy them to object storage (CloudCasa’s secure storage by default). The default is snapshot only, but Snapshot and copy is the safer option. The Advanced options section allows you to choose the target storage for your backup and set several less commonly needed performance-related options.

Next you can select pre and post-backup application hooks to execute. These are generally only needed for special applications like databases that need to be put in a specific state for backup.

See also

For more information on application hooks see App Hooks.

Next select the policy to apply to this backup. If you create a backup with no policy, it will not run automatically but can be started manually on an ad hoc basis.

Finally, you will be presented with a summary of your selections and prompted to enter a name for the backup. You can also enter optional tags to help identify it. Lastly, you can choose “Run now” if you want to start a backup right away.

See also

For more information on backup job creation, see Cluster Backup Wizard.

You’re done!

That’s all there is to it! Now you can sit back and relax, knowing that your Kubernetes clusters are protected.