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 are restoring an AKS, EKS, or GKE cluster, and you have linked your Azure, AWS, or GCP cloud accounts under Configuration/Cloud Accounts, CloudCasa will have backed up the cloud metadata associated with your cluster. This will allow it to create a new 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 recovery point

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.

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

The Restore Backup wizard will now show you the backup name and timestamp of the recovery point that you have selected.

Next you can choose what to restore - whether you want to restore all namespaces in the backup, or only selected namespaces or resources. If you choose to select namespaces, you will be given a list of namespaces from which you can select. Remember that only namespaces included in the backup will be shown. Also, namespaces cannot be over-written, so if you want to restore an existing namespace to a cluster, you will need to delete the old one first. 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 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 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. If you wish to select specific files or directories from a PVC for restore, you can do that using the file browser. If you are restoring KubeVirt VMs, additional options are available to help with that as well.

See also

See VM Restore for more information about restoring KubeVirt VMs.

Click Next again, and you’ll be presented with destination options. You can choose to restore to the original cluster or to an alternate cluster using the Cluster drop-down under Select Destination. By default, the restore will go to the original cluster. If you have linked cloud accounts, you can also choose to automatically create a new EKS, AKS, or GKE cluster to restore to here.

Next, you can choose “Restore transforms” such as renaming restored namespaces individually or by adding a prefix and/or suffix. You can also change storage classes here, which you may need to do if you are restoring from a cluster with a different type of storage from the source.

Next, you can choose to configure restore App Hooks, which you should usually only need in special cases.

Finally, you will be shown a summary and prompted to name the restore job. Restore jobs have names so that you can more easily track the status of them. The system will also save the job under its name so that you can modify and re-run it later. You can name it whatever you want. Nobody will judge you.

See also

See Cluster Restore Wizard for more information about configuring a restore job.

Now click Restore and CloudCasa will do the rest! You can watch the progress of your restore job in the Dashboard Activity pane. You can also edit and re-run it, if you wish, under the Clusters/Restores tab.