[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-30 UTC。"],[],[],null,["# Snapshot a PersistentVolume\n===========================\n\nYou can use the Kubernetes volume snapshot feature for\n[Persistent volumes and dynamic provisioning](/kubernetes-engine/docs/concepts/persistent-volumes)\nin your GKE clusters.\n\nVolume snapshots let you create a copy of your volume at a specific point\nin time. You can use this copy to bring a volume back to a prior state or to\nprovision a replacement volume.\n\nYou can provision and attach volume snapshots with the following components:\n\n- [VolumeSnapshotClass](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/)\n- [VolumeSnapshot](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)\n- [VolumeSnapshotContent](https://kubernetes.io/docs/concepts/storage/volume-snapshots/#volume-snapshot-contents)\n\nRequirements\n------------\n\nTo use volume snapshots on GKE on Azure, you must have the following:\n\n- A volume using a Container Storage Interface (CSI) driver that supports\n snapshots. The Azure Disk\n and Azure File drivers that\n GKE on Azure uses by default support snapshots.\n\n | **Note:** The Azure File CSI driver doesn't support restoring from a snapshot. For more information, see [Overview of share snapshots for Azure Files](https://docs.microsoft.com/en-us/azure/storage/files/storage-snapshots-files).\n\n For a list of all CSI drivers that support snapshots, see the \"Other features\"\n column in\n [Drivers](https://kubernetes-csi.github.io/docs/drivers.html)\n in the Kubernetes documentation.\n- Have an existing `PersistentVolumeClaim` to use for a snapshot. The\n `PersistentVolume` you use for a snapshot source must be managed by a CSI\n driver. You can verify that you're using a CSI driver by checking that the\n `PersistentVolume` spec has a `csi` section with `driver: disk.csi.azure.com`\n or `file.csi.azure.com`.\n If your cluster\n [Dynamically provisions PersistentVolumes](/kubernetes-engine/docs/concepts/persistent-volumes#dynamic_provisioning)\n by the CSI driver as described in the following sections, it's managed by\n the CSI driver.\n\nBefore you begin\n----------------\n\n- [Create a cluster](/kubernetes-engine/multi-cloud/docs/azure/how-to/create-cluster)\n- [Connect to your cluster](/kubernetes-engine/multi-cloud/docs/azure/how-to/connect-and-authenticate-to-your-cluster)\n\nCreate and use a volume snapshot\n--------------------------------\n\nThe examples in this document show you how to do the following tasks:\n\n1. [Create an example `PersistentVolumeClaim` and `Pod`](#create-pod).\n2. [Create a VolumeSnapshot](#create-snapshot).\n3. [Restore the volume snapshot](#restore-snapshot).\n4. [Verify that the restoration worked](#verify-restore).\n\nTo use a volume snapshot, you must complete the following steps:\n\n1. Create a `VolumeSnapshot` object to request a snapshot of an existing PersistentVolumeClaim.\n2. Reference the `VolumeSnapshot` in a `PersistentVolumeClaim` to restore a volume to that snapshot or create a new volume using the snapshot.\n\n### Create an example `PersistentVolumeClaim` and `Pod`\n\n1. To create the `PersistentVolumeClaim` object, save the following manifest as\n `example-pvc.yaml`:\n\n apiVersion: v1\n kind: PersistentVolumeClaim\n metadata:\n name: example-pvc\n spec:\n storageClassName: standard-rwo\n accessModes:\n - ReadWriteOnce\n resources:\n requests:\n storage: 1Gi\n\n For `spec.storageClassName`, you can specify any storage class that uses a\n supported CSI driver. This example uses the default `standard-rwo` storage\n class.\n2. Apply the manifest:\n\n kubectl apply -f example-pvc.yaml\n\n3. Create a Pod that writes the current date and time to the volume. To create a\n Pod, save the following manifest as `snapshot-shell.yaml`:\n\n apiVersion: v1\n kind: Pod\n metadata:\n name: snapshot-shell\n spec:\n terminationGracePeriodSeconds: 10\n containers:\n - name: linux\n image: ubuntu:bionic\n command: [\"/bin/sh\"]\n args: [\"-c\", \"echo $(date -u) \u003e\u003e /data/out.txt\"]\n volumeMounts:\n - name: snapshot-volume\n mountPath: /data\n restartPolicy: Never\n volumes:\n - name: snapshot-volume\n persistentVolumeClaim:\n claimName: example-pvc\n\n4. Apply the manifest:\n\n kubectl apply -f snapshot-shell.yaml\n\n5. Check the status of the Pod:\n\n kubectl get pod snapshot-shell\n\n It might take some time for the Pod to run and complete. You can run the\n preceding command until you see an output similar to the following: \n\n NAME READY STATUS RESTARTS AGE\n snapshot-shell 0/1 Completed 0 24s\n\n### Create a VolumeSnapshot\n\nA `VolumeSnapshot` object is a request for a snapshot of an existing\n`PersistentVolumeClaim` object. When you create a `VolumeSnapshot` object,\nyour cluster automatically creates and binds it with a `VolumeSnapshotContent`\nobject, which is a resource in your cluster like a `PersistentVolume` object.\n\n1. Save the following manifest as `volumesnapshot.yaml`.\n\n apiVersion: snapshot.storage.k8s.io/v1\n kind: VolumeSnapshot\n metadata:\n name: example-snapshot\n spec:\n source:\n persistentVolumeClaimName: example-pvc\n\n2. Apply the manifest:\n\n kubectl apply -f volumesnapshot.yaml\n\n After you create a volume snapshot, your cluster creates a corresponding\n `VolumeSnapshotContent` object. This object stores the snapshot and bindings\n of `VolumeSnapshot` objects. You do not interact with `VolumeSnapshotContents`\n objects directly.\n3. Confirm that your cluster created the `VolumeSnapshotContents` object:\n\n kubectl get volumesnapshotcontents\n\n The output is similar to the following: \n\n NAME AGE\n snapcontent-cee5fb1f-5427-11ea-a53c-42010a1000da 55s\n\n#### Confirm the volume snapshot is ready\n\nAfter the volume snapshot content is created, the CSI driver you specified in\nthe `VolumeSnapshotClass` creates a snapshot on the corresponding storage\nsystem. After your cluster creates a snapshot on the storage system and binds it\nto a `VolumeSnapshot` object, the snapshot is ready to use. You can check the\nstatus by running the following command: \n\n kubectl get volumesnapshot \\\n -o custom-columns='NAME:.metadata.name,READY:.status.readyToUse'\n\nIf the snapshot is ready to use, the output is similar to the following: \n\n NAME READY\n example-snapshot true\n\n### Restore the volume snapshot\n\nYou can reference a `VolumeSnapshot` in a `PersistentVolumeClaim` to provision\na new volume with data from an existing volume or restore a volume to a\nstate that you captured in the snapshot.\n\nTo reference a `VolumeSnapshot` in a `PersistentVolumeClaim`, add the `dataSource`\nfield to your `PersistentVolumeClaim`.\n\nIn this example, you reference the `VolumeSnapshot` that you created in a new\n`PersistentVolumeClaim` and create a Pod that mounts the\n`PersistentVolumeClaim`.\n\n1. Save the following manifest as `pvc-restore.yaml`:\n\n apiVersion: v1\n kind: PersistentVolumeClaim\n metadata:\n name: pvc-restore\n spec:\n dataSource:\n name: example-snapshot\n kind: VolumeSnapshot\n apiGroup: snapshot.storage.k8s.io\n storageClassName: standard-rwo\n accessModes:\n - ReadWriteOnce\n resources:\n requests:\n storage: 1Gi\n\n | **Note:** The namespace of the `PersistentVolumeClaim` must be the same as the namespace of the `VolumeSnapshot`.\n2. Apply the manifest:\n\n kubectl apply -f pvc-restore.yaml\n\n3. Launch a temporary Pod that mounts the PVC to the Pod and prints the\n contents of `out.txt` to logs.\n\n Save the following manifest as `restore-log.yaml`: \n\n apiVersion: v1\n kind: Pod\n metadata:\n name: restore-verify\n spec:\n volumes:\n - name: restore-data\n persistentVolumeClaim:\n claimName: pvc-restore\n containers:\n - name: shell-container\n image: ubuntu:bionic\n volumeMounts:\n - mountPath: \"/data\"\n name: restore-data\n command: [ \"/bin/sh\" ]\n args: [\"-c\", \"cat /data/out.txt\", \"exit\", \"1\"]\n restartPolicy: Never\n\n4. Apply the manifest:\n\n kubectl apply -f restore-log.yaml\n\n### Check that the snapshot restored successfully\n\nThe Pod you created in the previous step reads from the snapshot. To view the\ndata from the snapshot, use the `kubectl logs` command. \n\n kubectl logs restore-verify\n\nThe output should include a timestamp from the snapshot.\n\nClean up\n--------\n\nTo avoid incurring charges for the resources used on this page,\nfollow these steps.\n\n1. Delete the `VolumeSnapshot`:\n\n kubectl delete volumesnapshot example-snapshot\n\n \u003cbr /\u003e\n\n | **Note:** If a volume snapshot's `VolumeSnapshotClass` has `deletionPolicy:Delete`, the corresponding `VolumeSnapshotContent` and the physical snapshot on the storage system are also deleted. If it has a `deletionPolicy:Retain` the underlying snapshot is retained.\n2. Delete the temporary Pod:\n\n kubectl delete -f restore-log.yaml\n\n3. Delete the Pod:\n\n kubectl delete -f snapshot-shell.yaml\n\n4. Delete the `PersistentVolumeClaim` objects:\n\n kubectl delete pvc example-pvc pvc-restore\n\nWhat's next\n-----------\n\n- Read the Kubernetes [Volume Snapshot](https://kubernetes.io/docs/concepts/storage/volume-snapshots/) documentation.\n- [Install additional CSI drivers](/kubernetes-engine/multi-cloud/docs/azure/how-to/storage-drivers)."]]