Backup and Restore of VMs on Kubernetes
CloudCasa fully supports backup and restore of VMs running on Kubernetes, sometimes known as Cloud-native Virtualization or Kubernetes-native Virtual Machines. This includes VMs running under KubeVirt, Red Hat OpenShift Virtualization, and SUSE Virtualization/Harvester. CloudCasa’s VM-related features allow the selection of individual VMs for backup or restore, enable consistent backups of VMs, and even allow for the restore of individual files from within backed up VM filesystems.
Backing up VMs
➤ Log into CloudCasa
You’ll need a CloudCasa login if you don’t already have one. You can have a free CloudCasa SaaS account within minutes. Point your favorite web browser to home.cloudcasa.io and create one. 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.
➤ Add your clusters
Configure your cluster(s) by clicking “Add cluster” under Clusters/Overview. Then enter your cluster name and description and click “Register cluster”. 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.
Note that clusters running in AWS, Azure, or GCP can also be auto-discovered if your cloud accounts are configured in CloudCasa. See cloudaccounts:Cloud Accounts for more details.
➤ Create a backup policy
A backup policy allows you to define when backups that use it will run and for how long the resulting recovery points 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.
➤ Define a backup
Go to the Clusters/Backups page and click “Define Backup”. The cluster backup wizard will open. It has several steps.
First, select the cluster you wish to back up. In this case, this will be the cluster you just defined.
Next, select which VMs you wish to back up. The simplest thing to do is to accept the default, which is to back up the entire cluster. If you wish to back up only selected VMs, there are several ways to accomplish this. In the Selections step of the cluster backup wizard, you can use standard selections, selecting VMs based on namespace and labels, or you can use the VMs/PVCs tab to easily select individual VMs. Just open the resource browser by clicking on Select resources, and choose specific VMs for backup. The resource browser has multiple views available. Choose VMs to select from a table view of VMs, sortable by VM name or Namespace name. The Search box will filter by VM name.
The advantage of selecting VMs based on namespace and/or labels is that matching is performed when the backup runs. If you add additional VMs into a namespace, or add a label used for selection to additional VMs, those VMs will automatically be backed up in the next run. If you select specific VMs for backup, that selection is obviously static.
When selecting VMs for backup, all associated resources are also automatically selected for backup.
Note that CloudCasa supports pre-snapshot syncing of KubeVirt VMs during backup, migration, and replication jobs. This allows for filesystem-consistent backup of VM-based workloads. The QEMU Guest Agent (GA) must be installed on the VMs to support this. The function is invoked automatically if the GA is active. We recommend installing the GA on your KubeVirt VMs to help guarantee backup consistency.
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.
➤ Check your backup job status
You can check on the status of your backup job while it is running or after it has run using the Activity details pane. The Activity details pane is reachable by clicking on a job in the Dashboard/Activity page or in the Dashboard’s Activity tab. A VMs tab has been added to the pane for backup, restore, replication, and migration jobs. It displays status info for individual KubeVirt VMs. The status of each VM will update in real time while a job is running.
See also
Restoring VMs
➤ Select the cluster and recovery point to restore from
In CloudCasa, there are several ways to start defining a restore job, and any one will work equally well. One is to go to the Clusters/Restores page and click the “Define Restore” button. The cluster restore wizard will open. You will be prompted to select the cluster to restore from, and then which specific recovery point to use.
➤ Choose what to restore
There is an easy way of selecting specific resources for restore, including VMs, using the new resource browser. This is done by selecting the “Specific resources” tab in the “Select Resources” step of the cluster restore wizard. Clicking “Select resources” will then open the resource browser. After that, just click on the resources you want in order to select them. In this case look for resources of type “virtualmachine”. Note that selecting a VM will automatically include all resource related to it, making restore of individual VMs simple.
➤ Choose a destination cluster
Next you must choose a destination cluster for your restore operation. This can be any active cluster configured in CloudCasa, or optionally a new EKS, AKS, or GKE cluster to be created in the cloud. For a VM restore, you would normally select a destination cluster that already exists and that is already properly configured to run VMs. The original source cluster is selected by default.
➤ VM-specific restore options
In the Restore transforms step you can set VM-specific restore options in the VM options section.
Clear MAC address(es) - Specifies that MAC addresses for restored VMs should be cleared and new addresses should be assigned. This defaults to on. Disable it to preserve the saved MAC addresses for restored VMs. Do this only if you are sure that it will not result in duplicate MAC addresses on your network!
Generate new firmware UUID - Specifies that new firmware UUIDs should be generated for restored VMs. This defaults to off.
Run Strategy - This field controls whether and how restored VMs are started after restore. You can select any valid Run Strategy option or select “Use strategy from backup” to retain the saved run strategy for each VM from the backup. If you are uncertain, we recommend selecting “Halted” and booting VMs manually after restore.
See also
For more information on VM restore options see VM Restore.
➤ Run the restore
You can select post-restore application hooks in the “App Hooks” step, but these are not typically needed for VM restores.
In the “Summary” step, you should enter a name for the restore job (it will be saved with this name), and leave the “Run now” switch on to start the restore immediately. Then click “Save & Restore” to save the restore job and run it.
➤ Check your restore job status
You can check on the status of your restore job while it is running or after it has run using the Activity details pane. The Activity details pane is reachable by clicking on a job in the Dashboard/Activity page or in the Dashboard’s Activity tab. A VMs tab has been added to the pane for backup, restore, replication, and migration jobs. It displays status info for individual KubeVirt VMs. The status of each VM will update in real time while a job is running.
See also
See the CloudCasa Pro Restore Guide and the Cluster Restore Wizard documentation page for more information on defining restores.
Restoring individual files from VMs
Since VMs typically use block type PVs that are opaque to the Kubernetes cluster itself, the normal CloudCasa file-level restore facility will not work with them. But fear not! File-level restore is still available. You can retrieve individual files from a VM’s filesystems by using the Recovery Point File Browser.
➤ Select a recovery point to restore from
Select “Files” from recovery point actions for any “Copy” type recovery point in the list. This will open the Recovery Point File Browser.
➤ Browsing and downloading files
Use the browser to choose the VM you are interested in, and click the Browse icon next to it to open the VM file browser. The VM file browser will actually mount an image of the VM filesystem, so you will need to choose a proxy cluster and select the PVC(s) you are interested in browsing. The Proxy Cluster can be any cluster that supports running VMs and has access to the backup storage containing the recovery point. It defaults to the source cluster.
Note that you may need to wait a few minutes for file data to be retrieved. You can then browse the VM’s filesystems and select files to be retrieved. These files can be downloaded directly to your workstation or to another system as a zip file. Click Download and choose “Download Now” or “Create Download Link”. Download links will expire in 1 hour, by default.
See also
For more information see Browsing Recovery Points.