CloudCasa Pro Restore Guide

When you need to do a restore, you may not be having a good day and you are likely to be in a hurry. The CloudCasa team has your back! We’ve put together this quick restore guide to help make the process as easy for you as possible.

➤ Step 1 - Re-create your cluster if necessary

First, does the cluster you wish to restore to exist or do you need to re-create it? If it exists, and is registered in CloudCasa, you can go on to step 3. If it doesn’t, you will need to create a new cluster.

If your backup used CSI snapshots of persistent volumes (PVs) rather than copies, you will need to create it using storage that has access to your existing snapshots, and the CSI driver will need to have the same name as before so that your snapshots can be accessed.

If you have linked your Azure, AWS, or GCP cloud accounts under Configuration/Cloud Accounts, CloudCasa can create a new AKS, EKS, or GKE cluster for you automatically, if you wish. In this case, skip ahead to step 3.

➤ Step 2 - Re-register your cluster if necessary

If you had to manually re-create your cluster, or if the cloudcasa-io namespace was deleted from your cluster for some reason, you will need to re-register the cluster with CloudCasa before you can start to restore. This is easy. Just log in to the CloudCasa UI, click on the Clusters tab and select Overview. Now select your cluster in the list on the left. If the CloudCasa agent isn’t running on the cluster the state will not be “Active”.

If you previously installed the agent using a Helm chart or marketplace like Rancher or Digital Ocean 1-click, just make a note of the displayed cluster ID and re-install the agent as you installed it before. If you previously installed the agent using kubectl, note the kubectl command displayed at the bottom of the Cluster details tab. This is the same kubectl command that you used to register your cluster the first time. Run it against your cluster again now to re-register it.

Within a few minutes, the cluster state should change to Active in the Configuration tab. If it doesn’t, verify that the agent pod has started in the cloudcasa-io namespace, and that your network configuration allows outgoing TCP connections from your cluster to the CloudCasa service (agent.cloudcasa.io) on port 443.

➤ Step 3 - Choose a cluster and recovery point to restore from

For convenience, there are several ways to start defining a restore job in CloudCasa. Any one will work equally well. For the record, they are:

Go to Clusters/Recovery Points, choose a recovery point, and select the Restore action.
Go to Clusters/Backups, choose a backup, and select the Restore action.
Go to Clusters/Overview, select a cluster, select the Recovery Points tab, choose a recovery point, and select the Restore action.
Go to Clusters/Overview, select a cluster, select the Backups tab, choose a backup, and select the Restore action.
Go to Clusters/Restores, select Define Restore, then choose the cluster and recovery point.
Go to the Dashboard Cluster Backups tab, choose a backup, and select the Restore action.

Here we’ll say to go to the Clusters/Overview page and select the cluster you wish to restore from. Next select the Recovery Points tab, find the recovery point you wish to restore from, and click the Restore icon. The Restore Cluster wizard will open.

See also

See the Overview of Clusters page for more info on the Clusters Overview and Cluster Dashboard pages.

➤ Step 4 - Create and run a restore job

Next you must choose what to restore - whether you want to restore all namespaces in the backup, or only selected namespaces or resources, or even individual files. If you choose to select namespaces, you will be presented with a list of namespaces from which you can select. Remember that only namespaces included in the backup will be shown. You can also rename namespaces when restoring (later). You can add labels to be used to select resources for restore as well. These are key:value pairs, and will not be validated by the UI. You can add them one at a time or add multiple pairs at once, separated by spaces. Finally, you need to choose whether or not to restore PVs. If you toggle off the Exclude persistent volumes option (it is off by default), PVs will be restored using the snapshots or copies associated with the recovery point you’ve selected. Remember that if you have selected specific namespaces or labels for restore, only PVs in the namespaces or with the labels you’ve selected will be restored.

Note

Namespaces will not be over-written by default, so if you want to restore to an existing namespace on a cluster, you will need to either delete the old one first or select the “Overwrite existing resources” option in the “Restore transforms” step.

Note that CloudCasa has many additional restore capabilities that make special restore scenarios easier. For example, if you wish to select one or more specific Kubernetes resources for restore, you can do so using the resource browser under the Specific resources tab. If you wish to select specific files or directories from a PVC for restore, you can do that using the file browser under the Files tab. If you are restoring KubeVirt VMs, additional options are available to help with that as well.