Skip to main content
Version: 3.4

Backup & Restore Loft

This guide describes how to backup and restore the Loft management plane. For backing up the connected clusters, please reuse a regular Kubernetes backup solution such as velero.

Loft saves its state as Kubernetes CRD objects, these can be either backed up via velero or through a special Loft CLI command that we have created for convenience that saves all relevant Kubernetes resources to a single file. Loft CLI allows you to backup these components whenever required. Below Resources will be part of the backup:

  • ClusterRoleTemplates
  • ClusterAccesses
  • SpaceConstraints
  • Users
  • Teams
  • SharedSecrets
  • AccessKeys
  • Apps
  • SpaceTemplates
  • VirtualClusterTemplates
  • Clusters & Cluster Secrets
  • Projects
  • VirtualClusterInstances
  • SpaceInstances
  • ProjectSecrets

To take a backup using the defaults, you can run the following command. This will dump the manifests of all the above listed components to a file in the current directory named 'backup.yaml'

loft backup

Alternatively, you may specify the name for the backup file by running the command as:

loft backup --filename loft-backup.yaml

In some scenarios, Loft may have been installed in a different namespace instead of the default 'loft' namespace. You can provide this to the command as below:

loft backup --namespace my-namespace

You can also choose to exclude certain components from the backup by supplying the names as a comma-seperated string like below. This will exclude users and teams from the backup.

loft backup --skip users,teams

Restoring Loft from backup​

The backup YAML file contains the manifests for the resources of the Loft Management plane. Hence, it can be used as any other Kubernetes manifest file. To restore, simply apply the backup to your cluster using the below command: 

kubectl apply -f <backup-filename>.yaml

Note that you will likely see lots of warning messages similar to the following:

Warning: resource apps/argocd is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.

These are just warnings and should not affect the restoration task!

Multiple Kubernetes Clusters with the same Loft Config

Make sure that you are not installing Loft (and Loft Agents) into cluster(s) with Loft already running! Multiple Loft instances running on the same cluster(s) can lead to conflicts in reconciliation and could cause unexpected problems!