You are looking at the documentation of a prior release. To read the documentation of the latest release, please visit here.

New to KubeDB? Please start here.

KubeDB Snapshot

KubeDB operator maintains another Custom Resource Definition (CRD) for database backups called Snapshot. Snapshot object is used to take backup or restore from a backup.

Before You Begin

At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube.

Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps here.

To keep things isolated, this tutorial uses a separate namespace called demo throughout this tutorial.

$ kubectl create ns demo
namespace "demo" created

$ kubectl get ns demo
demo    Active  5s

Note: Yaml files used in this tutorial are stored in docs/examples/elasticsearch folder in GitHub repository kubedb/cli.

Prepare Database

We need an Elasticsearch object in Running phase to perform backup operation. If you do not already have an Elasticsearch instance running, create one first.

$ kubectl create -f
elasticsearch "infant-elasticsearch" created

Below the YAML for the Elasticsearch crd we have created above.

kind: Elasticsearch
  name: infant-elasticsearch
  namespace: demo
  version: "6.3-v1"
  storageType: Ephemeral

Here, we have used spec.storageType: Ephemeral. So, we don’t need to specify storage section. KubeDB will use emptyDir volume for this database.

Verify that the Elasticsearch is running,

$ kubedb get es -n demo infant-elasticsearch
NAME                   STATUS    AGE
infant-elasticsearch   Running   11m

Populate database

Let’s insert some data so that we can verify that the snapshot contains those data. Check how to connect with the database from here.

$ curl -XPUT --user "admin:fqvzdvz3" "localhost:9200/test/snapshot/1?pretty" -H 'Content-Type: application/json' -d'
    "title": "Snapshot",
    "text":  "Testing instand backup",
    "date":  "2018/02/13"
$ curl -XGET --user "admin:fqvzdvz3" "localhost:9200/test/snapshot/1?pretty"
  "_index" : "test",
  "_type" : "snapshot",
  "_id" : "1",
  "_version" : 1,
  "found" : true,
  "_source" : {
    "title" : "Snapshot",
    "text" : "Testing instand backup",
    "date" : "2018/02/13"

Now, we are ready to take backup of this database infant-elasticsearch.

Instant backup

Snapshot provides a declarative configuration for backup behavior in a Kubernetes native way.

Below is the Snapshot object created in this tutorial.

kind: Snapshot
  name: instant-snapshot
  namespace: demo
  labels: Elasticsearch
  databaseName: infant-elasticsearch
  storageSecretName: gcs-secret
    bucket: kubedb


  • metadata.labels should include the type of database.
  • spec.databaseName indicates the Elasticsearch object name, infant-elasticsearch, whose snapshot is taken.
  • spec.storageSecretName points to the Secret containing the credentials for snapshot storage destination.
  • spec.gcs.bucket points to the bucket name used to store the snapshot data.

In this case, Elasticsearch tells KubeDB operator that this Snapshot belongs to an Elasticsearch object. Only Elasticsearch controller will handle this Snapshot object.

Note: Snapshot and Secret objects must be in the same namespace as Elasticsearch, infant-elasticsearch.

Snapshot Storage Secret

Storage Secret should contain credentials that will be used to access storage destination. In this tutorial, snapshot data will be stored in a Google Cloud Storage (GCS) bucket.

For that a storage Secret is needed with following 2 keys:

GOOGLE_PROJECT_IDRequired. Google Cloud project ID
GOOGLE_SERVICE_ACCOUNT_JSON_KEYRequired. Google Cloud service account json key
$ echo -n '<your-project-id>' > GOOGLE_PROJECT_ID
$ mv downloaded-sa-json.key > GOOGLE_SERVICE_ACCOUNT_JSON_KEY
$ kubectl create secret -n demo generic gcs-secret \
    --from-file=./GOOGLE_PROJECT_ID \
secret "gcs-secret" created
$ kubectl get secret -n demo gcs-secret -o yaml
apiVersion: v1
kind: Secret
  creationTimestamp: 2018-02-13T06:35:36Z
  name: gcs-secret
  namespace: demo
  resourceVersion: "4308"
  selfLink: /api/v1/namespaces/demo/secrets/gcs-secret
  uid: 19a77054-1088-11e8-9e42-0800271bdbb6
type: Opaque

Snapshot storage backend

KubeDB supports various cloud providers (S3, GCS, Azure, OpenStack Swift and/or locally mounted volumes) as snapshot storage backend. In this tutorial, GCS backend is used.

To configure this backend, following parameters are available:

spec.gcs.bucketRequired. Name of bucket
spec.gcs.prefixOptional. Path prefix into bucket where snapshot data will be stored

An open source project osm is used to store snapshot data into cloud.

To learn how to configure other storage destinations for snapshot data, please visit here.

Now, create the Snapshot object.

$ kubectl create -f created

Let’s see Snapshot list of Elasticsearch infant-elasticsearch.

$ kubectl get snap -n demo,
NAME               DATABASENAME           STATUS      AGE
instant-snapshot   infant-elasticsearch   Succeeded   47s

KubeDB operator watches for Snapshot objects using Kubernetes API. When a Snapshot object is created, it will launch a Job that runs the elasticdump command and uploads the output files to cloud storage using osm.

Snapshot data is stored in a folder called {bucket}/{prefix}/kubedb/{namespace}/{elasticsearch}/{snapshot}/.

Once the snapshot Job is completed, you can see the output of the elasticdump command stored in the GCS bucket.


From the above image, you can see that the snapshot data files for index test are stored in your bucket.

If you open this file, you will see the data you have created previously.

      "text":"Testing instand backup",

Let’s see the Snapshot list for Elasticsearch infant-elasticsearch by running kubedb describe command.

$ kubedb describe es -n demo infant-elasticsearch
Name:               infant-elasticsearch
Namespace:          demo
CreationTimestamp:  Fri, 05 Oct 2018 16:45:56 +0600
Labels:             <none>
Status:             Running
Replicas:           1  total
  StorageType:      Ephemeral
  Capacity:  0

  Name:               infant-elasticsearch
  CreationTimestamp:  Fri, 05 Oct 2018 16:45:58 +0600
  Annotations:        <none>
  Replicas:           824639991608 desired | 1 total
  Pods Status:        1 Running / 0 Waiting / 0 Succeeded / 0 Failed

  Type                Pod                     StartTime                      Phase
  ----                ---                     ---------                      -----
  master|client|data  infant-elasticsearch-0  2018-10-05 16:45:58 +0600 +06  Running

  Name              Bucket     StartTime                        CompletionTime                   Phase
  ----              ------     ---------                        --------------                   -----
  instant-snapshot  gs:kubedb  Fri, 05 Oct 2018 17:27:55 +0600  Fri, 05 Oct 2018 17:28:10 +0600  Succeeded

  Type    Reason              Age   From                    Message
  ----    ------              ----  ----                    -------
  Normal  Successful          44m   Elasticsearch operator  Successfully created Service
  Normal  Successful          44m   Elasticsearch operator  Successfully created Service
  Normal  Successful          44m   Elasticsearch operator  Successfully created StatefulSet
  Normal  Successful          44m   Elasticsearch operator  Successfully created Elasticsearch
  Normal  Successful          44m   Elasticsearch operator  Successfully patched StatefulSet
  Normal  Successful          43m   Elasticsearch operator  Successfully patched Elasticsearch
  Normal  Successful          43m   Elasticsearch operator  Successfully patched StatefulSet
  Normal  Successful          43m   Elasticsearch operator  Successfully patched Elasticsearch
  Normal  Starting            2m    Job Controller          Backup running
  Normal  SuccessfulSnapshot  2m    Job Controller          Successfully completed snapshot

From the above output, we can see in Snapshots: section that we have one successful snapshot.

Delete Snapshot

If you want to delete snapshot data from storage, you can delete Snapshot object.

$ kubectl delete snap -n demo instant-snapshot
snapshot "instant-snapshot" deleted

Once Snapshot object is deleted, you can’t revert this process and snapshot data from storage will be deleted permanently.

Cleaning up

To cleanup the Kubernetes resources created by this tutorial, run:

$ kubectl patch -n demo es/infant-elasticsearch -p '{"spec":{"terminationPolicy":"WipeOut"}}' --type="merge"
$ kubectl delete -n demo es/infant-elasticsearch

$ kubectl delete ns demo

Next Steps