New to Stash? Please start here.
A BackupSession is a Kubernetes CustomResourceDefinition(CRD) which represents a backup run of the respective target referenced by a BackupConfiguration in a Kubernetes native way.
Stash operator creates a Kubernetes CronJob according to the schedule defined in a BackupConfiguration. On each backup schedule, this CronJob creates a BackupSession object. It points to the respective BackupConfiguration. The controller that runs inside backup sidecar (in case of backup via jobs, it is stash operator itself) watches this BackupSession object and start taking backup instantly.
You can also create a BackupSession object manually to trigger backup instantly.
Like any official Kubernetes resource, a BackupSession has TypeMeta, ObjectMeta and Spec , Status sections.
A sample BackupSession created for backing up the volumes of a Deployment is shown below,
apiVersion: stash.appscode.com/v1beta1
kind: BackupSession
metadata:
name: deployment-stash-demo-1564743309
namespace: demo
spec:
invoker:
apiGroup: stash.appscode.com
kind: BackupConfiguration
name: deployment-stash-demo
status:
totalHosts: 1
phase: Succeeded
sessionDuration: 43.044662123s
stats:
- hostname: host-0
phase: Succeeded
duration: 43.044662123s
snapshots:
- name: 79b223e2
path: /source/data-1
processingTime: "0:04"
size: 41 B
uploaded: 693 B
fileStats:
modifiedFiles: 0
newFiles: 1
totalFiles: 1
unmodifiedFiles: 0
- name: ab6fef46
path: /source/data-2
processingTime: "0:03"
size: 41 B
uploaded: 693 B
fileStats:
modifiedFiles: 0
newFiles: 1
totalFiles: 1
unmodifiedFiles: 0
Here, we are going to describe the various sections of a BackupSession object.
Metadatametadata.name indicates the name of the BackupSession. This name is automatically generated by respective CronJob and it follows the following pattern: <BackupConfiguration name>-<creation timestamp in Unix epoch seconds>.
metadata.namespace indicates the name of the BackupSession. It is same as the namespace of respective BackupConfiguration object.
metadata.labels holds respective BackupConfiguration name as a label. Stash backup sidecar container use this label to watch only the BackupSessions of that BackupConfiguration.
If you create
BackupSessionmanually to trigger a backup instantly, make sure that you have addedbackup-configuration: <BackupConfiguration name>label to yourBackupSession. Otherwise, it will not trigger backup for workloads (those resources that are backed up using sidecar).
SpecA BackupSession object has the following fields in the spec section:
spec.invoker specifies the apiGroup, kind, and name of the respective object which is responsible for invoking this backup session.
Status.status section of BackupSession shows stats and progress of backup process in this session.A backup sidecar container or job updates the respective fields under .status section after it completes its task. .status section consists of the following fields:
Not every pod or replica of the target is subject of backup. Thus, we refer those entities that are subject of backup as a host. status.totalHosts specifies the total number of hosts that will be backed up for this BackupSession. For more details on how many hosts will be backed up for which types of workload, please visit here.
status.phase indicates the overall phase of the backup process for this BackupSession. status.phase will be Succeeded only if the phase of all hosts are Succeeded. If any of the hosts fail to complete its backup, status.phase will be Failed.
status.sessionDuration indicates the total time taken to complete backup of all hosts in this session.
status.stats section is an array of backup statistics about individual hosts. Each host adds its statistics in this array after completing its backup process.
Each stats entry consists of the following fields:
hostname indicates the name of the host.phase indicates the backup phase of this host.duration indicates the total time taken to complete backup for this host.spec.target.paths field of BackupConfiguration object. The snapshots field holds statistics of each of these individual snapshots. Each snapshot statistics has the following fields:
name indicates the name of the snapshot.path indicates the file path that was backed up in this snapshot.size indicates the size of data to backup from this path.uploaded indicates the size of data that was uploaded to the backend for this snapshot. This could be much smaller than size if some data was already uploaded in the backend in previous backup sessions.processingTime indicates the time taken to process the data of the target path.fileStats field show statics of files that were backed up in this snapshot.
totalFiles shows the total number of files that were backed up in this snapshot.newFiles shows the number of new files that were backed up in this snapshot.modifiedFiles shows the number of files that were modified since last backup of this directory.unmodifiedFiles shows the number of files that haven’t changed since the last backup of this path.error shows the reason for failure if the backup process failed for this host.Stash uses two different models for backup depending on the target type. It uses sidecar model for Kubernetes workloads and job model for rest of the targets. In the sidecar model, Stash injects a sidecar inside the targeted workload and the sidecar is responsible for taking backup. In the job model, Stash launches a job to take a backup of the target.
Stash uses an identifier called host to separate the backed up data of different subject in the backed. This host identification process depends on the backup model and the target types. The backup strategy and host identification strategy for different types of target is explained below.
Kubernetes Workloads:
Stash uses sidecar model to backup Kubernetes workloads. However, not every sidecar takes backup. How many sidecars will take backup depends on the type of the workload. We can divide them into the following categories:
Stand-alone PVC:
Stash uses job model to backup a stand-alone PVC. Stash launches a job to backup the targeted PVC. This job is identified as host-0. In this case, the total number of host is 1.
Databases:
Stash uses job model to backup a database. Stash launches a job to backup the targeted database. In this case, the number of hosts depends on the database type.
VolumeSnapshot:
Stash uses job model for taking volume snapshots. Each volume is considered as different hosts and they are identified by their name. Hence, the number of total hosts for VolumeSnapshot is the number of targeted volumes. However, since VolumeSnapshot is handled by the respective CSI driver, host identifier does not play any role to separate their data.