Cluster Backup Wizard

The Cluster Backup Wizard allows you to create and edit Kubernetes backup jobs. It consists of several steps, not all of which will appear in all cases. You can jump back and forth between steps by clicking on the step names on the left-hand side of the wizard.

Defining a Kubernetes backup job

  1. In the Cluster step of the Kubernetes backup wizard you must select which cluster to back up from the list of active clusters. Note that depending on how you reached the wizard, the source cluster may already be selected for you. In that case, the wizard will open on the next step. After choosing a cluster, click Next.

  2. In the Selections step, you choose exactly what will be backed up using the following options:

    Namespaces

    Select either Full Cluster or Select Namespaces. Choosing Select Namespaces will prompt you to select the specific namespaces to include in the backup. Choosing Full Cluster (the default) will include all namespaces. Choosing Full Cluster and then Exclude namespaces will allow you to exclude specific namespaces.

    Select resource types (optional)

    Allows you to back up only specific Kubernetes resources types.

    Select labels (optional)

    Enter key-value pairs to specify the labels for the object that you want to protect in the cluster.

    Tip

    If you enter multiple label selectors separated by spaces in the Select Labels field, the relationship between them is assumed to be logical AND. So if you enter a:b c:d, it means that a must equal b AND c must equal d in order for the selector to match.

    CloudCasa will also allow you to enter a single key with multiple comma-separated values, and the relationship between these is assumed to be logical OR. So entering a:b,c means that a must equal b OR c. These can be combined, so entering a:b,c x:y means that a must equal b OR c AND x must equal y. That’s equivalent to (a == b || a == c) && x == y for you C lovers out there. Note that OR is not currently possible between different keys.

    Include Persistent Volumes

    Enable this option to back up Kubernetes Persistent Volumes in the selected namespaces. It is on by default.

    Snapshot only or Snapshot and copy

    This determines the type of backup for persistent volumes (PVs). Choosing Snapshot will only create snapshots of PVs, whereas choosing Snapshot and copy will create snapshots and then copy the data off of the created snapshots and send it to external storage. No matter which options you select for PVs, resource data is always sent to external storage.

    Tip

    In CloudCasa, there are two basic data protection methods for persistent volumes:

    Copy (Backup)

    Copying PV data from a cluster to external storage, that is, either CloudCasa Storage or user-supplied storage such as your own Amazon S3 bucket. For more information about CloudCasa Storage, see Service Plans and Settings; or, for user-supplied storage, see Storage.

    Snapshot

    Create a snapshot in local storage.

    Advanced Options

    Opening the Advanced options section will allow you to set the following options:

    Destination storage for copy (for Snapshot and Copy only)

    Select one of the following options:

    Inherit from cluster preferences

    Use the default destination for the cluster that you specified in the Clusters page.

    CloudCasa Storage

    Use the CloudCasa Storage. Select the provider from Amazon S3 (AWS) or Microsoft Azure Blob storage (azure) and the region of the data center. See Service Plans to upgrade the Service Plan and expand the capacity of CloudCasa Storage for your organization.

    User-provided Storage

    Select one of the user-defined object storage endpoints that you registered in the Storage page.

    Concurrent streams (for Snapshot and Copy only)

    Select a number of the data transfer streams between your cluster data and the destination storage during the backup job, between 1 stream and 16 streams. The default number is 2 streams.

    Max speed per stream (for Snapshot and Copy only)

    Specify the maximum bandwidth for the data transfer between your cluster data and the destination storage during the backup job in MB per second. Or, leave this field blank so as not to limit the bandwidth. The default value is blank for “Unlimited”.

    Data mover pod timeout (for Snapshot and Copy only)

    Time that the agent waits for the data mover pod to start once snapshot PVCs are bound. This should only need to be changed in special cases, for example when backing up Longhorn volumes using snapshots.

    Copy from live Longhorn PVs (for Snapshot and Copy only)

    By default CloudCasa copy backups read from snapshots, but mounting a Longhorn snapshot can take a long time due to Longhorn’s copy activity. If you enable this option, CloudCasa will read directly from the live Longhorn PVs instead, making backups run faster and use less resources at the expense of crash consistency. When enabling this option, you should consider using app hooks in order to obtain application consistent backups.

    Exclude unattached PVCs

    By default, CloudCasa will include unattached PVCs in backups. Enabling this options will cause unattached PVCs to be excluded from the backup. Be aware that there is currently no option to restore unattached PVCs from Snapshot and Copy backups.

    Enable storage class mapping for PV snapshots mounted during backup (for Snapshot and Copy only)

    This option allows you to use different storage classes when PV snapshots are mounted for copying the data off during Snapshot and Copy backup operations. This may be useful, for example, to indicate to your storage system that less replicas or a different type of storage should be used for these transient volumes than for normal production volumes. By default, the storage class of the original source volume will be used.

    CSI snapshot timeout

    The amount of time the agent will wait for a PV snapshot to become ready when mounting. The default is 10 minutes, which should be adequate for most applications. PVs using certain storage systems such as Longhorn may require this to be increased.

  3. In the App Hooks step you can choose to add pre-backup application hooks, post-backup application hooks, or both.

    See also

    For more information about App Hooks, see App Hooks.

  4. In the Policy step, you can choose a policy for the backup. Policies define schedules and retention periods for your backups as well as retention options such as SafeLock. You can see your policies under Configuration/Policies. If you need to define a new policy you can click Add policy + at the top right. If you don’t select a policy, your backup won’t be scheduled automatically, but can be run manually on an ad-hoc basis. Click Next to proceed.

    See also

    For more information about policies, see Policies.

  5. Review the Summary of the backup settings to verify that they are correct. In this step you can also enter the following:

    Backup name

    You must assign a name for the backup job.

    Add Tags (optional)

    Key-value pairs that you can use to help identify and manage the backup job in CloudCasa.

    If you didn’t select a policy, you’ll be given the option to select Run now to immediately start an ad-hoc backup. Note that in this case you must separately specify a retention period for this ad-hoc run. When you’re done, click Create or Create & Run.

Your new backup job is defined! If you selected the “Run now” option, it will start to execute immediately. If not, you can run it manually in the Dashboard or the Protection/Cluster Backups page. We recommend always doing a test run of newly defined backup jobs.

Defining a Kubernetes Velero backup job

Defining a Velero backup job using CloudCasa for Velero is nearly identical to the above procedure. The differences are the following:

  • In the selections step, Type Snapshot or Copy can be selected, but not Snapshot and Copy, as Velero does not support this. The additional option Follow pod annotations is provided. This allows the pod annotations to control copy operations. Also, not all options appear under Advanced options, since some do not apply.

  • The Policy step will not appear, since Velero does not support global policies. Instead, a Velero Settings step appears which allows entry of the following:

    • Include cluster scoped resources - Auto (default), Yes, or No

    • Backup Storage Location

    • Volume Snapshot Locations

    • Schedule (optional) - If not provided, backup will run immediately.

    • Retention days - The number of days that recovery points will be retained.

  • On the summary page, the Edit YAML button allows you to edit the YAML for the backup definition before saving it.