You are looking at the documentation of a prior release. To read the documentation of the latest release, please visit here.
Sometimes, a single component may not meet the requirement for your application. For example, in order to deploy a WordPress, you will need a Deployment for the WordPress and another Deployment for a database to store its contents. Now, you may want to backup both of the deployment and database together as they are parts of a single application.
BackupBatch is a Kubernetes
CustomResourceDefinition(CRD) which lets you configure backup for multiple co-related components(workload, database, etc.) together.
Like any official Kubernetes resource, a
BackupBatch object to backup multiple co-related components is shown below:
apiVersion: stash.appscode.com/v1beta1 kind: BackupBatch metadata: name: deploy-backup-batch namespace: demo spec: repository: name: minio-repo namespace: demo schedule: "*/3 * * * *" members: - target: alias: db ref: apiVersion: apps/v1 kind: AppBinding name: wordpress-mysql task: name: mysql-backup-8.0.14 - target: alias: app ref: apiVersion: apps/v1 kind: Deployment name: wordpress volumeMounts: - name: wordpress-persistent-storage mountPath: /var/www/html paths: - /var/www/html exclude: - /var/www/html/my-file.html - /var/www/html/*.json executionOrder: Parallel hooks: preBackup: exec: command: - /bin/sh - -c - echo "Sample PreBackup hook demo" containerName: my-database-container postBackup: exec: command: - /bin/sh - -c - echo "Sample PostBackup hook demo" containerName: my-database-container retryConfig: maxRetry: 3 delay: 10m timeOut: 1h30m retentionPolicy: name: 'keep-last-10' keepLast: 10 prune: true
Here, we are going to describe the various sections of
BackupBatch object has the following fields in the
spec.driver indicates the mechanism used to backup. Currently, Stash supports
VolumeSnapshotter as drivers. The default value of this field is
Restic. For more details, please see here.
spec.repository.name indicates the
Repository crd name that holds necessary backend information where the backed up data will be stored.
spec.executionOrder specifies whether Stash should backup the targets sequentially or parallelly. If
spec.executionOrder is set to
Parallel, Stash will start backup of all the targets simultaneously. If it is set to
Sequential, Stash will not start backup of a target until all the previous members have completed their backup process. The default value of this field is
spec.members field specifies a list of targets to backup. Each member consists of the following fields:
target : Each member has a target specification. The target specification of a member is the same as the target specification of a
BackupConfiguration explained here.
runtimeSettings allows to configure runtime environment for the backup sidecar or job. You can specify runtime settings at both pod level and container level. For more details, please see here.
tempDir : Stash mounts an
emptyDir for holding temporary files. It is also used for
caching for faster backup performance. You can configure the
tempDir section. You can also disable
caching using this field. For more details, please see here.
interimVolumeTemplate : For some targets (i.e. some databases), Stash can’t directly pipe the dumped data to the uploading process. In this case, it has to store the dumped data temporarily before uploading to the backend.
interimVolumeTemplate specifies a PVC template for holding those data temporarily. Stash will create a PVC according to the template and use it to store the data temporarily. This PVC will be deleted according to the backupHistoryLimit. For more details, please see here.
hooks : Each member has its own hook field which allows you to execute member-specific pre-backup or post-backup hooks. For more details about hooks, please visit here.
spec.hooks allows performing some global actions before and after the backup process of the members. You can send HTTP requests to a remote server via
httpPost. You can check whether a TCP port is open using
tcpSocket hooks. You can also execute some commands using
spec.hooks.preBackuphooks are executed on each backup session before taking backup of any of the members.
spec.hooks.postBackuphooks are executed on each backup session after taking backup of all the members.
For more details on how hooks work in Stash and how to configure different types of hook, please visit here.
spec.runtimeSettings This runtime settings is applicable for CronJob(used to create
BackupSession) only. For more details, please see here.
spec.backupHistoryLimit specifies the number of
BackupSession and its associate resources (Job, PVC etc.) to keep for debugging purposes. The default value of this field is 1. Stash will clean up the old
BackupSession and it’s associate resources after each backup session according to
spec.paused can be used as
enable/disable switch for backup. If it is set
true, Stash will not take any backup of the target specified by this BackupBatch.
spec.retentionPolicy specifies the policy to follow for cleaning old snapshots. For more details, please see here.
spec.retryConfig specifies a retry logic for failed backup. For more details, please see here.
spec.timeOut specifies the maximum duration of the backup. For more details, please see here.
BackupBatch object has the following fields in the
observedGeneration : The most recent generation observed by the
conditions : The
status.conditions shows current backup setup condition for this BackupBatch. The following conditions are set by the Stash operator:
|Indicates whether the respective Repository object was found or not.|
|Indicates whether the respective backend secret was found or not.|
|Indicates whether the backup triggering CronJob was created or not.|
BackupBatch. Each entry has the following two fields:
The following conditions are set for the members of a
|Indicates whether the backup target was found or not.|
|Indicates whether |
BackupBatchto backup data from here.