---
title: "Back up a cluster with Velero"
description: "Back up an E2E Kubernetes cluster's namespaces and volume data to an E2E Object Storage bucket with Velero, and restore them."
content_type: "how-to"
product: "kubernetes"
platform: "MyAccount"
url: "/myaccount/kubernetes/how-to/back-up-a-cluster-with-velero/"
topic: ["operate"]
relationships: {"requires":["/myaccount/kubernetes/how-to/connect-with-kubectl/","/myaccount/object-storage/how-to/create-a-bucket/","/myaccount/object-storage/how-to/generate-an-access-key/"]}
---

# Back up a cluster with Velero

Velero is an open-source backup tool that runs in your cluster. It saves a namespace's Kubernetes
resources, and the data on its volumes, to an S3-compatible bucket, and restores them into the
cluster later. These steps use an E2E Object Storage bucket, and were tested end to end on a cluster
in Delhi.

## Before you begin

- kubectl is connected to the cluster. See
  [Connect to a cluster with kubectl](/myaccount/kubernetes/how-to/connect-with-kubectl/).
- Helm is installed on your computer, and uses the same kubeconfig.
- You have an E2E Object Storage bucket, and an access key attached to it with a role that can read
  and write, such as **Bucket Writer**. Keep the key's access key and secret key at hand. See
  [Create a bucket](/myaccount/object-storage/how-to/create-a-bucket/) and
  [Generate an access key](/myaccount/object-storage/how-to/generate-an-access-key/).
- The data you want to back up is on claims made through the storage class `csi-rbd-sc`. A restore
  creates new volumes through a storage class, and a volume made on the **Persistent Volume** tab
  has none. See
  [Create a volume from a claim](/myaccount/kubernetes/how-to/use-persistent-volumes/#create-a-volume-from-a-claim).

## Give Velero the bucket's access key

1. Write the access key to a file named `credentials-velero`. Replace `<access-key>` and
   `<secret-key>` with the key's values:

   ```ini
   [default]
   aws_access_key_id = <access-key>
   aws_secret_access_key = <secret-key>
   ```

2. Store the file in a secret in the `velero` namespace:

   ```bash
   kubectl create namespace velero
   kubectl create secret generic velero-cloud -n velero --from-file=cloud=credentials-velero
   ```

Keep the file as safe as a password, and delete it from your computer once the secret exists.

## Install Velero

1. Write a file named `values.yaml` with these settings. Replace `<bucket>` with your bucket's name:

   ```yaml
   initContainers:
     - name: velero-plugin-for-aws
       image: velero/velero-plugin-for-aws:v1.14.4
       volumeMounts:
         - mountPath: /target
           name: plugins
   configuration:
     backupStorageLocation:
       - name: default
         provider: aws
         bucket: <bucket>
         config:
           region: us-east-1
           s3ForcePathStyle: "true"
           s3Url: https://objectstore.e2enetworks.net
     volumeSnapshotLocation: []
     defaultVolumesToFsBackup: true
   snapshotsEnabled: false
   deployNodeAgent: true
   ```

   These are the values the test used. E2E Object Storage accepts both path-style and virtual-hosted
   addressing, and does not check the region a client sends, so the region and path-style settings
   are working values rather than requirements. For a bucket in Chennai, use the Chennai endpoint,
   `https://in-south1-objectstore.e2enetworks.net`. The last settings back up volumes by copying
   their files, through Velero's node agent, instead of taking snapshots.

2. Add the Velero chart repository, and install Velero with your values and the secret:

   ```bash
   helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
   helm install velero vmware-tanzu/velero --namespace velero --create-namespace --version 12.2.0 -f values.yaml --set credentials.existingSecret=velero-cloud
   ```

3. Check that Velero reaches the bucket:

   ```bash
   kubectl get backupstoragelocation -n velero
   ```

   The location named `default` reads `Available`.

## Back up a namespace

1. Write a file named `backup.yaml`. Replace `<backup-name>` with a name for this backup, and
   `<namespace>` with the namespace to back up:

   ```yaml
   apiVersion: velero.io/v1
   kind: Backup
   metadata:
     name: <backup-name>
     namespace: velero
   spec:
     includedNamespaces:
       - <namespace>
     defaultVolumesToFsBackup: true
   ```

2. Apply it, and check the backup's phase:

   ```bash
   kubectl apply -f backup.yaml
   kubectl get backup <backup-name> -n velero -o jsonpath='{.status.phase}'
   ```

   The backup reads InProgress, then `Completed`.

With the Velero CLI installed, `velero backup create <backup-name> --include-namespaces <namespace>`
does the same.

## Restore a namespace

1. Write a file named `restore.yaml`. Replace `<restore-name>` with a name for this restore:

   ```yaml
   apiVersion: velero.io/v1
   kind: Restore
   metadata:
     name: <restore-name>
     namespace: velero
   spec:
     backupName: <backup-name>
   ```

2. Apply it, and check the restore's phase:

   ```bash
   kubectl apply -f restore.yaml
   kubectl get restore <restore-name> -n velero -o jsonpath='{.status.phase}'
   ```

   The restore reads `Completed`. Its pods come back, and each claim that was backed up comes back
   as a new volume with the same data. To check, read a file from a restored pod with
   `kubectl exec`.

Your namespaces and their volume data now have a copy in your bucket that you can restore. For more
Velero options, such as scheduled backups, see the [Velero documentation](https://velero.io/docs/).
If a restored claim stays `Pending`, see
[A volume claim stays Pending](/myaccount/kubernetes/troubleshooting/kubernetes/#a-volume-claim-stays-pending).