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.
Snapshot is a representation of backup snapshot in a Kubernetes native way. Stash uses an Aggregated API Server to provide
list capabilities for snapshots from the backend.
This enables you to view some useful information such as
backed up path etc of a snapshot. This also provides the capability to restore a specific snapshot.
Like other official Kuberentes resources, a
Status sections. However, unlike other Kubernetes resources, it does not have a
Snapshot object is shown below,
Here, we are going to describe the various sections of a
metadata.name specifies the name of the
Snapshot object. It follows the following pattern,
<Repository crd name>-<first 8 digits of snapshot id>.
metadata.uid specifies the complete id of the respective restic snapshot in the backend.
metadata.creationTimestamp represents the time when the snapshot was created.
Snapshot object holds
hostname as a label in
metadata.labels section. This helps a user to query the snapshots of a particular repository and/or a particular host.
Snapshot object has the following fields in
status.gid indicates the group identifier of the user who took this backup.
status.hostname indicates the host identifier whose data has been backed up in this snapshot. In order to know how this host identifier are generated, please visit here.
status.paths indicates the paths that have been backed up in this snapshot.
status.repository indicates the name of the Repository crd where this Snapshot came from.
tree of the restic snapshot. For more details, please visit here.
uid of the user who took this backup. For
root user it is 0.
status.username indicates the name of the user who runs the backup process that took the backup.
status.tags indicates the tags of the snapshot.
In this section, we are going to show different types of operations you can perform on the Snapshots.
Stash lists Snapshots directly from the backend. This operation can take more time than the default request timeout of
kubectl. So, we are going to increase the request timeout through the
--request-timeout flag for get/list commands.
# List Snapshots of all Repositories in the current namespace
$ kubectl get snapshot --request-timeout=300s
# List Snapshots of all Repositories of all namespaces
$ kubectl get snapshot --all-namespaces --request-timeout=300s
# List Snapshots of all Repositories of a particular namespace
$ kubectl get snapshot -n demo --request-timeout=300s
# List Snapshots of a particular Repository
$ kubectl get snapshot -l repository=local-repo --request-timeout=300s
# List Snapshots from multiple Repositories
$ kubectl get snapshot -l 'repository in (local-repo,gcs-repo)' --request-timeout=300s
# List Snapshots of a particular host
$ kubectl get snapshot -l hostname=db --request-timeout=300s
# List Snapshots of a particular Repository and particular host
$ kubectl get snapshot -l repository=local-repo,hostname=db --request-timeout=300s
Viewing information of a particular Snapshot:
$ kubectl get snapshot [-n <namespace>] <snapshot name> -o yaml
$ kubectl get snapshot -n demo local-repo-02b0ed42 -o yaml
Snapshots listing facility with the help of an Aggregated API Server. Your cluster must support Aggregated API Server. Otherwise, you won’t be able to perform
list operation on
If you are using local backend, the respective pod that took the backup must be in
Running state. It is not necessary if you use cloud backends.