7.3. About volume snapshots


You can use volume snapshots with logical volume manager (LVM) thin volumes to help protect against data loss from applications running in a MicroShift node. MicroShift only supports the logical volume manager storage (LVMS) Container Storage Interface (CSI) provider.

注意

LVMS only supports the volumeBindingMode of the storage class being set to WaitForFirstConsumer. This setting means the storage volume is not provisioned until a pod is ready to mount it.

Example workload that deploys a single pod and PVC

$ oc apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim-thin
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: topolvm-provisioner-thin
---
apiVersion: v1
kind: Pod
metadata:
  name: base
spec:
  containers:
  - command:
	    - nginx
	    - -g
	    - 'daemon off;'
    image: registry.redhat.io/rhel8/nginx-122@sha256:908ebb0dec0d669caaf4145a8a21e04fdf9ebffbba5fd4562ce5ab388bf41ab2
    name: test-container
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - mountPath: /vol
      name: test-vol
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - name: test-vol
    persistentVolumeClaim:
      claimName: test-claim-thin
EOF

7.3.1. Creating a volume snapshot

To create a snapshot of a MicroShift storage volume, you must first configure RHEL for Edge and the node. In the following example procedure, the pod that the source volume is mounted to is deleted. Deleting the pod prevents data from being written to it during snapshot creation. Ensuring that no data is being written during a snapshot is crucial to creating a viable snapshot.

Prerequisites

  • User has root access to a MicroShift node.
  • MicroShift is running.
  • A device class defines an LVM thin-pool.
  • A volumeSnapshotClass specifies driver: topolvm.io.
  • Any workload attached to the source PVC is paused or deleted. This helps avoid data corruption.
重要

All writes to the volume must be halted while you are creating the snapshot. If you do not halt writes, your data might be corrupted.

Procedure

  1. Prevent data from being written to the volume during snapshotting by using one of the two following steps:

    1. Delete the pod to ensure that no data is written to the volume during snapshotting by running the following command:

      $ oc delete my-pod
    2. Scale the replica count to zero on a pod that is managed with a replication controller. Setting the count to zero prevents the instant creation of a new pod when one is deleted.
  2. After all writes to the volume are halted, run a command similar to the example that follows. Insert your own configuration details.

    Example snapshot configuration

    # oc apply -f <<EOF
    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot 
    1
    
    metadata:
      name: <snapshot_name> 
    2
    
    spec:
      volumeSnapshotClassName: topolvm-snapclass 
    3
    
      source:
        persistentVolumeClaimName: test-claim-thin 
    4
    
    EOF

    1
    Create a VolumeSnapshot object.
    2
    The name that you specify for the snapshot.
    3
    Specify the desired name of the VolumeSnapshotClass object.
    4
    Specify either persistentVolumeClaimName or volumeSnapshotContentName. In this example, a snapshot is created from a PVC named test-claim-thin.
  3. Wait for the storage driver to finish creating the snapshot by running the following command:

    $ oc wait volumesnapshot/<snapshot_name> --for=jsonpath\='{.status.readyToUse}=true'

Next steps

  1. When the volumeSnapshot object is in a ReadyToUse state, you can restore it as a volume for future PVCs. Restart the pod or scale the replica count back up to the desired number.
  2. After you have created the volume snapshot, you can remount the source PVC to a new pod.
重要

Volume snapshots are located on the same devices as the original data. To use the volume snapshots as backups, move the snapshots to a secure location.

7.3.2. Backing up a volume snapshot

Snapshots of data from applications running on a MicroShift node are created as read-only logical volumes (LVs) located on the same devices as the original data. You must manually mount local volumes before they can be copied as persistent volumes (PVs) and used as backup copies. To use a snapshot of a MicroShift storage volume as a backup, find it on the local host and then move it to a secure location.

To find specific snapshots and copy them, use the following procedure.

Prerequisites

  • You have root access to the host machine.
  • You have an existing volume snapshot.

Procedure

  1. Get the name of the volume snapshot by running the following command:

    $ oc get volumesnapshot -n <namespace> <snapshot_name> -o 'jsonpath={.status.volumeSnapshotContentName}'
  2. Get the unique identity of the volume created on the storage backend by using the following command and inserting the name retrieved in the previous step:

    $ oc get volumesnapshotcontent snapcontent-<retrieved_volume_identity> -o 'jsonpath={.status.snapshotHandle}'
  3. Display the snapshots by using the unique identity of the volume you retrieved in the previous step to determine which one you want to backup by running the following command:

    $ sudo lvdisplay <retrieved_snapshot_handle>

    Example output

    --- Logical volume ---
    LV Path                /dev/rhel/732e45ff-f220-49ce-859e-87ccca26b14c
    LV Name                732e45ff-f220-49ce-859e-87ccca26b14c
    VG Name                rhel
    LV UUID                6Ojwc0-YTfp-nKJ3-F9FO-PvMR-Ic7b-LzNGSx
    LV Write Access        read only
    LV Creation host, time rhel-92.lab.local, 2023-08-07 14:45:26 -0500
    LV Pool name           thinpool
    LV Thin origin name    a2d2dcdc-747e-4572-8c83-56cd873d3b07
    LV Status              available
    # open                 0
    LV Size                1.00 GiB
    Mapped size            1.04%
    Current LE             256
    Segments               1
    Allocation             inherit
    Read ahead sectors     auto
    - currently set to     256
    Block device           253:11

  4. Create a directory to use for mounting the LV by running the following command:

    $ sudo mkdir /mnt/snapshot
  5. Mount the LV using the device name for the retrieved snapshot handle by running the following command:

    $ sudo mount /dev/<retrieved_snapshot_handle> /mnt/snapshot
  6. Copy the files from the mounted location and store them in a secure location by running the following command:

    $ sudo cp -r /mnt/snapshot <destination>

7.3.3. Restoring a volume snapshot

The following workflow demonstrates snapshot restoration. In this example, the verification steps are also given to ensure that data written to a source persistent volume claim (PVC) is preserved and restored on a new PVC.

重要

A snapshot must be restored to a PVC of exactly the same size as the source volume of the snapshot. You can resize the PVC after the snapshot is restored successfully if a larger PVC is needed.

Procedure

  1. Restore a snapshot by specifying the VolumeSnapshot object as the data source in a persistent volume claim by entering the following command:

    $ oc apply -f <<EOF
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: snapshot-restore
    spec:
      accessModes:
      - ReadWriteOnce
      dataSource:
        apiGroup: snapshot.storage.k8s.io
        kind: VolumeSnapshot
        name: my-snap
      resources:
        requests:
          storage: 1Gi
      storageClassName: topolvm-provisioner-thin
    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: base
    spec:
      containers:
      - command:
          - nginx
    	    - -g
    	    - 'daemon off;'
        image: registry.redhat.io/rhel8/nginx-122@sha256:908ebb0dec0d669caaf4145a8a21e04fdf9ebffbba5fd4562ce5ab388bf41ab2
        name: test-container
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        volumeMounts:
        - mountPath: /vol
          name: test-vol
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      volumes:
      - name: test-vol
        persistentVolumeClaim:
          claimName: snapshot-restore
    EOF

Verification

  1. Wait for the pod to reach the Ready state:

    $ oc wait --for=condition=Ready pod/base
  2. When the new pod is ready, verify that the data from your application is correct in the snapshot.

7.3.4. Deleting a volume snapshot

You can configure how Red Hat build of MicroShift deletes volume snapshots.

Procedure

  1. Specify the deletion policy that you require in the VolumeSnapshotClass object, as shown in the following example:

    volumesnapshotclass.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: csi-hostpath-snap
    driver: hostpath.csi.k8s.io
    deletionPolicy: Delete 
    1

    1
    When deleting the volume snapshot, if the Delete value is set, the underlying snapshot is deleted along with the VolumeSnapshotContent object. If the Retain value is set, both the underlying snapshot and VolumeSnapshotContent object remain.
    If the Retain value is set and the VolumeSnapshot object is deleted without deleting the corresponding VolumeSnapshotContent object, the content remains. The snapshot itself is also retained in the storage back end.
  2. Delete the volume snapshot by entering the following command:

    $ oc delete volumesnapshot <volumesnapshot_name>

    Example output

    volumesnapshot.snapshot.storage.k8s.io "mysnapshot" deleted

  3. If the deletion policy is set to Retain, delete the volume snapshot content by entering the following command:

    $ oc delete volumesnapshotcontent <volumesnapshotcontent_name>
  4. Optional: If the VolumeSnapshot object is not successfully deleted, enter the following command to remove any finalizers for the leftover resource so that the delete operation can continue:

    重要

    Only remove the finalizers if you are confident that there are no existing references from either persistent volume claims or volume snapshot contents to the VolumeSnapshot object. Even with the --force option, the delete operation does not delete snapshot objects until all finalizers are removed.

    $ oc patch -n $PROJECT volumesnapshot/$NAME --type=merge -p '{"metadata": {"finalizers":null}}'

    Example output

    volumesnapshotclass.snapshot.storage.k8s.io "csi-ocs-rbd-snapclass" deleted

    The finalizers are removed and the volume snapshot is deleted.

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部