K10 Disaster Recovery

K10 Disaster Recovery (DR) aims to protect K10 from the underlying infrastructure failures. In particular, this feature provides the ability to recover the K10 platform in case of a variety of disasters such as the accidental deletion of K10, failure of underlying storage that K10 uses for its catalog, or even the accidental destruction of the Kubernetes cluster on which K10 is deployed.


K10 enables DR with the help of an internal policy to backup its own data stores and store these in an object storage bucket configured using a Kanister Profile.

Object Storage Configuration

To enable K10 DR, a Kanister Profile needs to be configured. This will use an object storage bucket to store data from K10's internal data stores and the cluster will need to have write permissions to this bucket.

Enabling K10 Disaster Recovery

K10 DR settings can be accessed from the Settings icon in the top-right corner of the dashboard or, for a new install, via the prompt at the bottom of the dashboard.


On the Settings page, select K10 Disaster Recovery and then click the Enabled button to enable disaster recovery.


If you have not previously created a Kanister Profile, an alert will appear prompting the creation of a profile. You can either click on create a Kanister profile link from the prompt or navigate to the Kanister configuration section under Settings.


Once you have created a Kanister Profile, you can enable K10 DR by clicking the Enabled button.


After enabling K10 DR, it is essential that you copy and save the cluster ID displayed on the page.

The cluster ID can also be extracted using the following kubectl command.

# Extract UUID of the `default` namespace
$ kubectl get namespace default -ojsonpath="{.metadata.uid}{'\n'}"

The above extracted UUID is used as a prefix to the object storage location where K10's data store snapshots are saved.

A policy to implement K10 DR will be created and can be viewed from the Policies page.


Currently, data exported by K10 for DR is encrypted via AES-256. It is highly recommended that you specify your own encryption key. You can refer to Data Secret Creation.

Disabling K10 Disaster Recovery

You can disable K10 DR by clicking on the Disabled button on the K10 Disaster Recovery page under Settings.


Recovering K10 From a Disaster


It is important to save the UUID of the source cluster as well as the credentials and object storage bucket information used in the Kanister Profile configuration above to completely recover K10 from a disaster.

Recovering from a K10 backup involves the following:

  • Install a fresh K10 instance

  • Provide bucket information and credentials for the object storage location where previous K10 backups are stored

  • Run the K10 restore command

Reinstall K10


If you are reinstalling K10 on the same cluster, it is important to clean up the namespace in which K10 was previously installed.

# Delete kasten-io namespace.
$ kubectl delete namespace kasten-io

K10 must be reinstalled before recovery. Please follow the instructions here.


It is important that you use the same Data Encryption Key as well as Metadata Encryption Key used during the K10 backup operation.

Provide Object Storage Configuration

Create a Kanister Profile with the object storage location configured to store K10 backups.

Restore K10 Backup


  • Source cluster ID

  • Kanister profile name from the previous step

# Install the helm chart that creates the K10 restore job and wait for completion of the `k10-restore` job
# Assumes that K10 is installed in 'kasten-io' namespace.
$ helm install kasten/k10restore --name k10-restore --namespace=kasten-io \
    --set sourceClusterID=<source-clusterID>,profile.name=<kanister-profile-name>
# Install the helm chart that creates the K10 restore job and wait for completion of the `k10-restore` job
# Assumes that K10 is installed in 'kasten-io' namespace.
$ helm install k10-restore kasten/k10restore --namespace=kasten-io \
    --set sourceClusterID=<source-clusterID>,profile.name=<kanister-profile-name>