Skip to main content
Version: 3.2

Create and manage local snapshots in Azure Snapshot

Summary and Key concepts

Summary:​

This article provides a detailed guide on how to create and manage snapshots of Portworx volumes in Kubernetes using Stork. It covers the process of creating snapshots for both single PVCs and groups of PVCs using label selectors, restoring snapshots to new or existing PVCs, and performing in-place restores. The article highlights the importance of using annotations for managing snapshot operations and explains how to handle snapshots across namespaces. Additionally, it includes guidance on verifying snapshots and restoring operations using the Kubernetes CLI tools like kubectl and Stork's CLI storkctl.

Kubernetes Concepts:​

  • PersistentVolumeClaim (PVC): A request for storage in Kubernetes, used for creating and restoring snapshots.
  • StorageClass: Defines how storage is provisioned, such as using the stork-snapshot-sc StorageClass for restoring snapshots.
  • Annotations: Metadata used to manage snapshots, including cross-namespace snapshot restoration.
  • ClusterRole: Defines permissions for managing snapshot operations across the Kubernetes cluster.

Portworx Concepts:​

  • Stork: A Portworx tool for managing storage operations, including snapshots and backups in Kubernetes.

  • VolumeSnapshot: A snapshot of a Portworx volume for backup and cloning.

  • VolumeSnapshotRestore: Used to restore a PVC from a snapshot, supporting both new PVCs and in-place restores.

This document will show you how to create snapshots of Portworx volumes and how you can clone those snapshots to use them in pods.

note

The suggested way to manage snapshots on Kuberenetes is to use Stork. If you are looking to create Portworx snapshots using PVC annotations, you will find instructions here.

Prerequisites​

Install Stork

This requires that you already have Stork installed and running on your Kubernetes cluster. If you fetched the Portworx specs from the Portworx spec generator in Portworx Central and used the default options, Stork is already installed.

Create snapshots​

With local snapshots, you can either snapshot individual PVCs one by one or snapshot a group of PVCs by using a label selector.

Restore snapshots​

Once you've created a snapshot, you can restore it to a new PVC or the original PVC.

Restore a local snapshot to a new PVC​

When you install Stork, it also creates a storage class called stork-snapshot-sc. This storage class can be used to create PVCs from snapshots.

To create a PVC from a snapshot, add the snapshot.alpha.kubernetes.io/snapshot annotation to refer to the snapshot name. If the snapshot exists in another namespace, you should specify the snapshot namespace with the stork.libopenstorage.org/snapshot-source-namespace annotation in the PVC.

The Retain policy is important if you need to keep the volume in place, even after removing the Kubernetes objects from a cluster.

note
  • As shown in the following example, the storageClassName should be the Stork StorageClass stork-snapshot-sc.
  • When using this storage class the PVC is creating with delete as Retain policy. However, if the source PVC is having the policy as retain, then this will not be inherited to the restored PVC. After the restore, you should manually verify the retain policy and change it if needed.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-snap-clone
  annotations:
    snapshot.alpha.kubernetes.io/snapshot: mysql-snapshot
spec:
  accessModes:
     - ReadWriteOnce
  storageClassName: stork-snapshot-sc
  resources:
    requests:
      storage: 2Gi

Once you apply the above spec, you will see a PVC created by Stork. This PVC will be backed by a Portworx volume clone of the snapshot created above.

kubectl get pvc

NAMESPACE   NAME                                   STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                AGE
default     mysql-data                             Bound     pvc-xxxxxxxx-xxxx-xxxx-xxxx-0214683e8447   2Gi        RWO            px-mysql-sc                 2d
default     mysql-snap-clone                       Bound     pvc-xxxxxxxx-xxxx-xxxx-xxxx-0214683e8447   2Gi        RWO            stork-snapshot-sc           2s

Restore a local snapshot to the original PVC​

When you perform an in-place restore to a PVC, Stork takes the pods using that PVC offline, restores the volume from the snapshot, then brings the pods back online.

note

In-place restore using VolumeSnapshotRestore works only for applications deployed using the stork scheduler. If you're not using the Stork scheduler, Portworx displays the following error when describing the VolumeSnapshotRestore resource:

Events:
  Type     Reason  Age               From   Message
  ----     ------  ----              ----   -------
  Warning  Failed  5s (x2 over 15s)  stork  application not scheduled by stork scheduler

  1. Create a VolumeSnapshotRestore YAML file specifying the following:

    • apiVersion as stork.libopenstorage.org/v1alpha1
    • kind as VolumeSnapshotRestore
    • metadata.name with the name of the object that performs the restore
    • metadata.namespace with the name of the target namespace
    • spec.sourceName with the name of the snapshot you want to restore
    • spec.sourceNamespace with the namespace in which the snapshot resides

    The following example restores data from a snapshot called mysql-snapshot which was created in the mysql-snap-restore-splocal namespace to a PVC called mysql-snap-inrestore in the default namespace:

    apiVersion: stork.libopenstorage.org/v1alpha1
    kind: VolumeSnapshotRestore
    metadata:
      name: mysql-snap-inrestore
      namespace: default
    spec:
      sourceName: mysql-snapshot
      sourceNamespace: mysql-snap-restore-splocal

  1. Place the spec into a file called mysql-cloud-snapshot-restore.yaml and apply it:

    kubectl apply -f mysql-cloud-snapshot-restore.yaml

  2. You can enter the following command to see the status of the restore process:

    storkctl get volumesnapshotrestore
    NAME                   SOURCE-SNAPSHOT   SOURCE-SNAPSHOT-NAMESPACE   STATUS          VOLUMES   CREATED
    mysql-snap-inrestore   mysql-snapshot    default                     Successful      1         23 Sep 19 21:55 EDT

    You can also use the kubectl describe command to retrieve more detailed information about the status of the restore process.

    Example:

    kubectl describe volumesnapshotrestore mysql-snap-inrestore
    Name:         mysql-snap-inrestore
    Namespace:    default
    Labels:       <none>
    Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                    {"apiVersion":"stork.libopenstorage.org/v1alpha1","kind":"VolumeSnapshotRestore","metadata":{"annotations":{},"name":"mysql-snap-inrestore...
    API Version:  stork.libopenstorage.org/v1alpha1
    Kind:         VolumeSnapshotRestore
    Metadata:
      Creation Timestamp:  2019-09-23T17:24:30Z
      Generation:          5
      Resource Version:    904014
      Self Link:           /apis/stork.libopenstorage.org/v1alpha1/namespaces/default/volumesnapshotrestores/mysql-snap-inrestore
      UID:                 xxxxxxxx-xxxx-xxxx-xxxx-000c295d6364
    Spec:
      Group Snapshot:    false
      Source Name:       mysql-snapshot
      Source Namespace:  default
    Status:
      Status:  Successful
      Volumes:
        Namespace:  default
        Pvc:        mysql-data
        Reason:     Restore is successful
        Snapshot:   k8s-volume-snapshot-xxxxxxxx-xxxx-xxxx-xxxx-320ff611f4ca
        Status:     Successful
        Volume:     pvc-xxxxxxxx-xxxx-xxxx-xxxx-000c295d6364
    Events:
      Type    Reason      Age   From   Message
      ----    ------      ----  ----   -------
      Normal  Successful  0s    stork  Snapshot in-Place  Restore completed

Last updated on