You are looking at the documentation of a prior release. To read the documentation of the latest release, please
visit here.
New to Stash? Please start here.
Using Stash with TLS secured Minio Server
Minio is an open source object storage server compatible with AWS S3 cloud storage service. This tutorial will show you how to use Stash to backup and restore a volume with a Minio backend. Here, we are going to backup the /source/data
folder of a busybox pod into a Minio bucket. Then, we are going to show how to recover this data into a PersistentVolumeClaim(PVC)
. We are going to also re-deploy deployment using this recovered volume.
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.
Install
Stash
in your cluster following the steps here.You should be familiar with the following Stash concepts:
You will need a TLS secured Minio server to store backed up data. If you already do not have a Minio server running, deploy one following the tutorial from here. For this tutorial, we have deployed Minio server in
storage
namespace and it is accessible throughminio.storage.svc
dns.
To keep things isolated, we are going to use a separate namespace called demo
throughout this tutorial.
$ kubectl create ns demo
namespace/demo created
Note: YAML files used in this tutorial are stored in /docs/examples/platforms/minio directory of appscode/stash repository.
Backup
In order to take backup, we need some sample data. Stash has some sample data in stash-data repository. As gitRepo volume has been deprecated, we are not going to use this repository as volume directly. Instead, we are going to create a configMap from the stash-data repository and use that ConfigMap as data source.
Let’s create a ConfigMap from these sample data,
$ kubectl create configmap -n demo stash-sample-data \
--from-literal=LICENSE="$(curl -fsSL https://raw.githubusercontent.com/appscode/stash-data/master/LICENSE)" \
--from-literal=README.md="$(curl -fsSL https://raw.githubusercontent.com/appscode/stash-data/master/README.md)"
configmap/stash-sample-data created
Deploy Workload:
Now, deploy the following Deployment. Here, we have mounted the ConfigMap stash-sample-data
as data source volume.
Below, the YAML for the Deployment we are going to create.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: stash-demo
name: stash-demo
namespace: demo
spec:
replicas: 1
selector:
matchLabels:
app: stash-demo
template:
metadata:
labels:
app: stash-demo
name: busybox
spec:
containers:
- args:
- sleep
- "3600"
image: busybox
imagePullPolicy: IfNotPresent
name: busybox
volumeMounts:
- mountPath: /source/data
name: source-data
restartPolicy: Always
volumes:
- name: source-data
configMap:
name: stash-sample-data
Let’s create the deployment we have shown above,
$ kubectl apply -f ./docs/examples/platforms/minio/deployment.yaml
deployment.apps/stash-demo created
Now, wait for deployment’s pod to go in Running
state.
$ kubectl get pod -n demo -l app=stash-demo
NAME READY STATUS RESTARTS AGE
stash-demo-7ccd56bf5d-n24vl 1/1 Running 0 16s
You can check that the /source/data/
directory of this pod is populated with data from the stash-sample-data
ConfigMap using this command,
$ kubectl exec -n demo stash-demo-7ccd56bf5d-n24vl -- ls -R /source/data
/source/data:
LICENSE
README.md
Now, we are ready to backup /source/data
directory into a Minio bucket.
Create Secret:
At first, we need to create a secret for Restic
crd. To configure this backend, the following secret keys are needed:
Key | Description |
---|---|
RESTIC_PASSWORD | Required . Password used to encrypt snapshots by restic |
AWS_ACCESS_KEY_ID | Required . Minio access key |
AWS_SECRET_ACCESS_KEY | Required . Minio secret access key |
CA_CERT_DATA | Required for TLS secured Minio server. Root certificate by which Minio server certificate is signed |
Create the secret as below,
$ echo -n 'changeit' > RESTIC_PASSWORD
$ echo -n '<your-minio-access-key-id-here>' > AWS_ACCESS_KEY_ID
$ echo -n '<your-minio-secret-access-key-here>' > AWS_SECRET_ACCESS_KEY
$ cat ./directory/of/root/certificate/ca.crt > CA_CERT_DATA
$ kubectl create secret generic -n demo minio-secret \
--from-file=./RESTIC_PASSWORD \
--from-file=./AWS_ACCESS_KEY_ID \
--from-file=./AWS_SECRET_ACCESS_KEY \
--from-file=./CA_CERT_DATA
secret/minio-secret created
Verify that the secret has been created successfully,
$ kubectl get secret -n demo minio-secret -o yaml
apiVersion: v1
data:
AWS_ACCESS_KEY_ID: bXktYWNjZXNzLWtleQ==
AWS_SECRET_ACCESS_KEY: bXktc2NyZXQta2V5
CA_CERT_DATA: <base64 endoded ca.crt data>
RESTIC_PASSWORD: Y2hhbmdlaXQ=
kind: Secret
metadata:
creationTimestamp: 2018-12-05T11:42:48Z
name: minio-secret
namespace: demo
resourceVersion: "36660"
selfLink: /api/v1/namespaces/demo/secrets/minio-secret
uid: e3a2f905-f882-11e8-9a81-0800272171a4
type: Opaque
Create Restic:
Now, we are going to create Restic
crd to take backup /source/data
directory of stash-demo
deployment. This will create a repository in the Minio bucket specified by s3.bucket
field and start taking periodic backup of /source/data
directory.
$ kubectl apply -f ./docs/examples/platforms/minio/restic.yaml
restic.stash.appscode.com/minio-restic created
Below, the YAML for Restic crd we have created above,
apiVersion: stash.appscode.com/v1alpha1
kind: Restic
metadata:
name: minio-restic
namespace: demo
spec:
selector:
matchLabels:
app: stash-demo
fileGroups:
- path: /source/data
retentionPolicyName: 'keep-last-5'
backend:
s3:
endpoint: 'https://minio.storage.svc'
bucket: stash-repo
prefix: demo
storageSecretName: minio-secret
schedule: '@every 1m'
volumeMounts:
- mountPath: /source/data
name: source-data
retentionPolicies:
- name: 'keep-last-5'
keepLast: 5
prune: true
If everything goes well, Stash will inject a sidecar container into the stash-demo
deployment to take periodic backup. Let’s check that sidecar has been injected successfully,
$ kubectl get pod -n demo -l app=stash-demo
NAME READY STATUS RESTARTS AGE
stash-demo-57656f6d74-hmc9z 2/2 Running 0 46s
Look at the pod. It now has 2 containers. If you view the resource definition of this pod, you will see that there is a container named stash
which running backup
command.
Verify Backup:
Stash will create a Repository
crd with name deployment.stash-demo
for the respective repository in Minio backend at first backup schedule. To verify, run the following command,
$ kubectl get repository deployment.stash-demo -n demo
NAME BACKUPCOUNT LASTSUCCESSFULBACKUP AGE
deployment.stash-demo 1 14s 1m
Here, BACKUPCOUNT
field indicates number of backup snapshot has taken in this repository.
Restic
will take backup of the volume periodically with a 1-minute interval. You can verify that backup snapshots has been created successfully by,
$ kubectl get snapshots -n demo -l repository=deployment.stash-demo
NAME AGE
deployment.stash-demo-c588c67c 4m3s
deployment.stash-demo-7dc0c17d 3m3s
deployment.stash-demo-21228047 2m3s
deployment.stash-demo-15873428 63s
deployment.stash-demo-a29263b1 3s
Here, we can see 5 last successful backup Snapshot taken by Stash in deployment.stash-demo
repository.
If you navigate to <bucket name>/demo/deployment/stash-demo
directory in your Minio Web UI. You will see, a repository has been created there.
To view the snapshot files, navigate to snapshots
directory of the repository,
Stash keeps all backup data encrypted. So, snapshot files in the bucket will not contain any meaningful data until they are decrypted.
Recovery
Now, consider that we have lost our workload as well as data volume. We want to recover the data into a new volume and re-deploy the workload.
At first, let’s delete Restic
crd, stash-demo
deployment and stash-sample-data
ConfigMap.
$ kubectl delete deployment -n demo stash-demo
deployment.extensions "stash-demo" deleted
$ kubectl delete restic -n demo minio-restic
restic.stash.appscode.com "minio-restic" deleted
$ kubectl delete configmap -n demo stash-sample-data
configmap "stash-sample-data" deleted
In order to perform recovery, we need Repository
crd deployment.stah-demo
and backend secret minio-secret
to exist.
In case of cluster disaster, you might lose
Repository
crd and backend secret. In this scenario, you have to create the secret again andRepository
crd manually. Follow the guide to understandRepository
crd structure from here.
Create PVC:
We will recover backed up data into a PVC. At first, we need to know available StorageClass in our cluster.
$ kubectl get storageclass
NAME PROVISIONER AGE
standard (default) k8s.io/minikube-hostpath 8h
Now, let’s create a PersistentVolumeClaim
where our recovered data will be stored.
$ kubectl apply -f ./docs/examples/platforms/minio/pvc.yaml
persistentvolumeclaim/stash-recovered created
Below the YAML for PersistentVolumeClaim
we have created above,
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: stash-recovered
namespace: demo
labels:
app: stash-demo
spec:
storageClassName: standard
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Mi
Check that if cluster has provisioned the requested claim,
$ kubectl get pvc -n demo -l app=stash-demo
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
stash-recovered Bound pvc-3d3b6a58-f886-11e8-9a81-0800272171a4 50Mi RWO standard 13s
Look at the STATUS
filed. stash-recovered
PVC is bounded to volume pvc-3d3b6a58-f886-11e8-9a81-0800272171a4
.
Create Recovery:
Now, we have to create a Recovery
crd to recover backed up data into this PVC.
$ kubectl apply -f ./docs/examples/platforms/minio/recovery.yaml
recovery.stash.appscode.com/minio-recovery created
Below, the YAML for Recovery
crd we have created above.
apiVersion: stash.appscode.com/v1alpha1
kind: Recovery
metadata:
name: minio-recovery
namespace: demo
spec:
repository:
name: deployment.stash-demo
namespace: demo
paths:
- /source/data
recoveredVolumes:
- mountPath: /source/data
persistentVolumeClaim:
claimName: stash-recovered
Wait until Recovery
job completes its task. To verify that recovery has completed successfully run,
$ kubectl get recovery -n demo minio-recovery
NAME REPOSITORYNAMESPACE REPOSITORYNAME SNAPSHOT PHASE AGE
minio-recovery demo deployment.stash-demo Succeeded 26s
Here, PHASE
Succeeded
indicates that our recovery has been completed successfully. Backup data has been restored in stash-recovered
PVC. Now, we are ready to use this PVC to re-deploy the workload.
If you are using Kubernetes version older than v1.11.0 then run following command and check status.phase
field to see whether the recovery succeeded or failed.
$ kubectl get recovery -n demo minio-recovery -o yaml
Re-deploy Workload:
We have successfully restored backed up data into stash-recovered
PVC. Now, we are going to re-deploy our previous deployment stash-demo
. This time, we are going to mount the stash-recovered
PVC as source-data
volume instead of ConfigMap stash-sample-data
.
Below, the YAML for stash-demo
deployment with stash-recovered
PVC as source-data
volume.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: stash-demo
name: stash-demo
namespace: demo
spec:
replicas: 1
selector:
matchLabels:
app: stash-demo
template:
metadata:
labels:
app: stash-demo
name: busybox
spec:
containers:
- args:
- sleep
- "3600"
image: busybox
imagePullPolicy: IfNotPresent
name: busybox
volumeMounts:
- mountPath: /source/data
name: source-data
restartPolicy: Always
volumes:
- name: source-data
persistentVolumeClaim:
claimName: stash-recovered
Let’s create the deployment,
$ kubectl apply -f ./docs/examples/platforms/minio/recovered-deployment.yaml
deployment.apps/stash-demo created
Verify Recovered Data:
We have re-deployed stash-demo
deployment with recovered volume. Now, it is time to verify that the recovered data are present in /source/data
directory.
Get the pod of new deployment,
$ kubectl get pod -n demo -l app=stash-demo
NAME READY STATUS RESTARTS AGE
stash-demo-69694789df-wq9vc 1/1 Running 0 14s
Run following command to view data of /source/data
directory of this pod,
$ kubectl exec -n demo stash-demo-69694789df-wq9vc -- ls -R /source/data
/source/data:
LICENSE
README.md
So, we can see that the data we had backed up from original deployment are now present in re-deployed deployment.
Cleanup
To cleanup the resources created by this tutorial, run following commands:
$ kubectl delete recovery -n demo minio-recovery
$ kubectl delete secret -n demo minio-secret
$ kubectl delete deployment -n demo stash-demo
$ kubectl delete pvc -n demo stash-recovered
$ kubectl delete repository -n demo deployment.stash-demo
$ kubectl delete ns demo
- To uninstall Stash from your cluster, follow the instructions from here.
- If you have deployed Minio server by following the tutorial we have linked in Before You Begin section, please clean-up Minio resources by following the cleanup section of that tutorial.