--- title: Backup and restore by using VM snapshots --- # Backup and restore by using VM snapshots {#virt-backup-restore-snapshots} You can back up and restore virtual machines (VMs) by using snapshots. Snapshots are supported by the following storage providers: - Red Hat OpenShift Data Foundation - Any other cloud storage provider with the Container Storage Interface (CSI) driver that supports the Kubernetes Volume Snapshot API To create snapshots of a VM in the `Running` state with the highest integrity, install the QEMU guest agent if it is not included with your operating system. The QEMU guest agent is included with the default Red Hat templates. > [!IMPORTANT] > Online snapshots are supported for virtual machines that have hot plugged virtual disks. However, hot plugged disks that are not in the virtual machine specification are not included in the snapshot. > > Ensure that the QEMU guest agent is installed and running on the virtual machine before you take an online snapshot. > > The QEMU guest agent stops responding to file system operations to ensure that the snapshot captures a consistent state. The QEMU guest agent takes a consistent snapshot by attempting to quiesce the VM file system. This ensures that in-flight I/O is written to the disk before the snapshot is taken. If the guest agent is not present, quiescing is not possible and a best-effort snapshot is taken. The conditions under which a snapshot is taken are reflected in the snapshot indications that are displayed in the web console or CLI. If these conditions do not meet your requirements, try creating the snapshot again or use an offline snapshot ## About snapshots {#virt-about-vm-snapshots_virt-backup-restore-snapshots} A *snapshot* represents the state and data of a virtual machine (VM) at a specific point in time. You can use a snapshot to restore an existing VM to a previous state (represented by the snapshot) for backup and disaster recovery or to rapidly roll back to a previous development version. A VM snapshot is created from a VM that is powered off (Stopped state) or powered on (Running state). When taking a snapshot of a running VM, the controller checks that the QEMU guest agent is installed and running. If so, it freezes the VM file system before taking the snapshot, and thaws the file system after the snapshot is taken. The snapshot stores a copy of each Container Storage Interface (CSI) volume attached to the VM and a copy of the VM specification and metadata. Snapshots cannot be changed after creation. You can perform the following snapshot actions: - Create a new snapshot - Create a clone of a virtual machine from a snapshot > [!IMPORTANT] > Cloning a VM with a vTPM device attached to it or creating a new VM from its snapshot is not supported. - List all snapshots attached to a specific VM - Restore a VM from a snapshot - Delete an existing VM snapshot ### VM snapshot controller and custom resources {#_vm_snapshot_controller_and_custom_resources} The VM snapshot feature introduces three new API objects defined as custom resource definitions (CRDs) for managing snapshots: - `VirtualMachineSnapshot`: Represents a user request to create a snapshot. It contains information about the current state of the VM. - `VirtualMachineSnapshotContent`: Represents a provisioned resource on the cluster (a snapshot). It is created by the VM snapshot controller and contains references to all resources required to restore the VM. - `VirtualMachineRestore`: Represents a user request to restore a VM from a snapshot. The VM snapshot controller binds a `VirtualMachineSnapshotContent` object with the `VirtualMachineSnapshot` object for which it was created, with a one-to-one mapping. ## About application-consistent snapshots and backups {#virt-about-application-consistent-backups_virt-backup-restore-snapshots} You can configure application-consistent snapshots and backups for Linux or Windows virtual machines (VMs) through a cycle of freezing and thawing. For any application, you can configure a script on a Linux VM or register on a Windows VM to be notified when a snapshot or backup is due to begin. On a Linux VM, freeze and thaw processes trigger automatically when a snapshot is taken or a backup is started by using, for example, a plugin from Velero or another backup vendor. The freeze process, performed by QEMU Guest Agent (QEMU GA) freeze hooks, ensures that before the snapshot or backup of a VM occurs, all of the VM’s filesystems are frozen and each appropriately configured application is informed that a snapshot or backup is about to start. This notification affords each application the opportunity to quiesce its state. Depending on the application, quiescing might involve temporarily refusing new requests, finishing in-progress operations, and flushing data to disk. The operating system is then directed to quiesce the filesystems by flushing outstanding writes to disk and freezing new write activity. All new connection requests are refused. When all applications have become inactive, the QEMU GA freezes the filesystems, and a snapshot is taken or a backup initiated. After the taking of the snapshot or start of the backup, the thawing process begins. Filesystems writing is reactivated and applications receive notification to resume normal operations. The same cycle of freezing and thawing is available on a Windows VM. Applications register with the Volume Shadow Copy Service (VSS) to receive notifications that they should flush out their data because a backup or snapshot is imminent. Thawing of the applications after the backup or snapshot is complete returns them to an active state. For more details, see the Windows Server documentation about the Volume Shadow Copy Service. ## Creating a snapshot by using the web console {#virt-creating-vm-snapshot-web_virt-backup-restore-snapshots} You can create a snapshot of a virtual machine (VM) by using the OpenShift Container Platform web console. **Prerequisites** - The `snapshot` feature gate is enabled in the YAML configuration of the `kubevirt` CR. - The VM snapshot includes disks that meet the following requirements: - The disks are data volumes or persistent volume claims. - The disks belong to a storage class that supports Container Storage Interface (CSI) volume snapshots. - The disks are *bound* to a persistent volume (PV) and *populated* with a datasource. **Procedure** 1. Navigate to **Virtualization** → **VirtualMachines** in the web console. 2. Select a VM to open the **VirtualMachine details** page. 3. Click the **Snapshots** tab and then click **Take Snapshot**. Alternatively, right-click the VM and select **Create snapshot** from the menu. 4. Enter the snapshot name. 5. Expand **Disks included in this Snapshot** to see the storage volumes to be included in the snapshot. 6. If your VM has disks that cannot be included in the snapshot and you wish to proceed, select **I am aware of this warning and wish to proceed**. 7. Click **Save**. ## Creating a snapshot by using the CLI {#virt-creating-vm-snapshot-cli_virt-backup-restore-snapshots} You can create a virtual machine (VM) snapshot for an offline or online VM by creating a `VirtualMachineSnapshot` object. **Prerequisites** - Ensure the `Snapshot` feature gate is enabled for the `kubevirt` CR by using the following command: ```terminal $ oc get kubevirt kubevirt-hyperconverged -n openshift-cnv -o yaml ``` Truncated output: ```yaml spec: developerConfiguration: featureGates: - Snapshot ``` - Ensure that the VM snapshot includes disks that meet the following requirements: - The disks are data volumes or persistent volume claims. - The disks belong to a storage class that supports Container Storage Interface (CSI) volume snapshots. - The disks are *bound* to a persistent volume (PV) and *populated* with a datasource. - Install the OpenShift CLI (`oc`). - Optional: Power down the VM for which you want to create a snapshot. **Procedure** 1. Create a YAML file to define a `VirtualMachineSnapshot` object that specifies the name of the new `VirtualMachineSnapshot` and the name of the source VM as in the following example: ```yaml apiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineSnapshot metadata: name: spec: source: apiGroup: kubevirt.io kind: VirtualMachine name: ``` 2. Create the `VirtualMachineSnapshot` object: ```terminal $ oc create -f .yaml ``` The snapshot controller creates a `VirtualMachineSnapshotContent` object, binds it to the `VirtualMachineSnapshot`, and updates the `status` and `readyToUse` fields of the `VirtualMachineSnapshot` object. **Verification** 1. Optional: During the snapshot creation process, you can use the `wait` command to monitor the status of the snapshot and wait until it is ready for use: 1. Enter the following command: ```terminal $ oc wait --for condition=Ready ``` 2. Verify the status of the snapshot: - `InProgress` - The snapshot operation is still in progress. - `Succeeded` - The snapshot operation completed successfully. - `Failed` - The snapshot operaton failed. > [!NOTE] > Online snapshots have a default time deadline of five minutes (`5m`). If the snapshot does not complete successfully in five minutes, the status is set to `failed`. Afterwards, the file system will be thawed and the VM unfrozen but the status remains `failed` until you delete the failed snapshot image. > > To change the default time deadline, add the `FailureDeadline` attribute to the VM snapshot spec with the time designated in minutes (`m`) or in seconds (`s`) that you want to specify before the snapshot operation times out. > > To set no deadline, you can specify `0`, though this is generally not recommended, as it can result in an unresponsive VM. > > If you do not specify a unit of time such as `m` or `s`, the default is seconds (`s`). 2. Verify that the `VirtualMachineSnapshot` object is created and bound with `VirtualMachineSnapshotContent` and that the `readyToUse` flag is set to `true`: ```terminal $ oc describe vmsnapshot ``` Example output: ```yaml apiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineSnapshot metadata: creationTimestamp: "2020-09-30T14:41:51Z" finalizers: - snapshot.kubevirt.io/vmsnapshot-protection generation: 5 name: mysnap namespace: default resourceVersion: "3897" selfLink: /apis/snapshot.kubevirt.io/v1beta1/namespaces/default/virtualmachinesnapshots/my-vmsnapshot uid: 28eedf08-5d6a-42c1-969c-2eda58e2a78d spec: source: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm status: conditions: - lastProbeTime: null lastTransitionTime: "2020-09-30T14:42:03Z" reason: Operation complete status: "False" type: Progressing - lastProbeTime: null lastTransitionTime: "2020-09-30T14:42:03Z" reason: Operation complete status: "True" type: Ready creationTime: "2020-09-30T14:42:03Z" readyToUse: true sourceUID: 355897f3-73a0-4ec4-83d3-3c2df9486f4f virtualMachineSnapshotContentName: vmsnapshot-content-28eedf08-5d6a-42c1-969c-2eda58e2a78d indications: - Online includedVolumes: - name: rootdisk kind: PersistentVolumeClaim namespace: default - name: datadisk1 kind: DataVolume namespace: default ``` where: `status` : The `status` field of the `Progressing` condition specifies if the snapshot is still being created. The `status` field of the `Ready` condition specifies if the snapshot creation process is complete. `readyToUse`:: Specifies if the snapshot is ready to be used. `virtualMachineSnapshotContentName`:: Specifies that the snapshot is bound to a `VirtualMachineSnapshotContent` object created by the snapshot controller. `indications`:: Specifies additional information about the snapshot, such as whether it is an online snapshot, or whether it was created with QEMU guest agent running. `includedVolumes`:: Lists the storage volumes that are part of the snapshot, as well as their parameters. 3. Check the `includedVolumes` section in the snapshot description to verify that the expected PVCs are included in the snapshot. ## Verifying online snapshots by using snapshot indications {#virt-verifying-online-snapshot-creation-with-snapshot-indications_virt-backup-restore-snapshots} Snapshot indications are contextual information about online virtual machine (VM) snapshot operations. Indications are not available for offline virtual machine (VM) snapshot operations. Indications are helpful in describing details about the online snapshot creation. **Prerequisites** - You must have attempted to create an online VM snapshot. **Procedure** 1. Display the output from the snapshot indications by performing one of the following actions: - Use the command line to view indicator output in the `status` stanza of the `VirtualMachineSnapshot` object YAML. - In the web console, click **VirtualMachineSnapshot** → **Status** in the **Snapshot details** screen. 2. Verify the status of your online VM snapshot by viewing the values of the `status.indications` parameter: - `Online` indicates that the VM was running during online snapshot creation. - `GuestAgent` indicates that the QEMU guest agent was active and successfully quiesced the guest file system for the online snapshot. This results in an application-consistent snapshot, preserving data integrity as if the applications had been gracefully shut down. - `NoGuestAgent` indicates that the QEMU guest agent was not installed, or not ready to quiesce the file system during the online snapshot. This results in a crash-consistent snapshot, which captures the VM’s state like an abrupt power-off. As a result, application consistency is not guaranteed, which causes a risk of data issues for critical applications. For higher reliability, install and run the guest agent, or retry the snapshot. - `QuiesceFailed` indicates that an attempt to quiesce the file system failed during the online snapshot process. This means that the snapshot was created, but it is not necessarily application-consistent. To achieve proper consistency, retry the snapshot. ## Restoring a VM from a snapshot by using the web console {#virt-restoring-vm-from-snapshot-web_virt-backup-restore-snapshots} You can restore a virtual machine (VM) to a previous configuration represented by a snapshot in the OpenShift Container Platform web console. **Procedure** 1. Navigate to **Virtualization** → **VirtualMachines** in the web console. 2. Select a VM to open the **VirtualMachine details** page. 3. If the VM is running, click the Options menu ![](/openshift-docs-markdown/images/kebab.png "Options menu") and select **Stop** to power it down. 4. Click the **Snapshots** tab to view a list of snapshots associated with the VM. 5. Select a snapshot to open the **Snapshot Details** screen. 6. Click the Options menu ![](/openshift-docs-markdown/images/kebab.png "Options menu") and select **Restore VirtualMachine from snapshot**. 7. Optional: In the **Volume restore policy** section, select how restored persistent volume claims (PVCs) are named: - **Prefix target name** - The restored PVC names use the target VM name as a prefix. This is the default setting. - **In place** - The restored PVCs overwrite the original PVCs with the same names. - **Randomize names** - The restored PVC names are randomly generated. 8. Click **Restore**. 9. Optional: You can also create a new VM based on the snapshot. To do so: 1. In the Options menu ![](/openshift-docs-markdown/images/kebab.png "Options menu") of the snapshot, select **Create VirtualMachine from Snapshot**. 2. Provide a name for the new VM. 3. Click **Create** ## Restoring a VM from a snapshot by using the CLI {#virt-restoring-vm-from-snapshot-cli_virt-backup-restore-snapshots} You can restore an existing virtual machine (VM) to a previous configuration by using the command line. You can only restore from an offline VM snapshot. **Prerequisites** - Install the OpenShift CLI (`oc`). - Power down the VM you want to restore. - Optional: Adjust what happens if the target VM is not fully stopped (*ready*). To do so, set the `targetReadinessPolicy` parameter in the `vmrestore` YAML configuration to one of the following values: - `FailImmediate` - The restore process fails immediately if the VM is not ready. - `StopTarget` - If the VM is not ready, it gets stopped, and the restore process starts. - `WaitGracePeriod 5` - The restore process waits for a set amount of time, in minutes, for the VM to be ready. This is the default setting, with the default value set to 5 minutes. - `WaitEventually` - The restore process waits indefinitely for the VM to be ready. - Optional: To control the naming of restored persistent volume claims (PVCs), you can set the `volumeRestorePolicy` parameter to one of the following values: - `PrefixTargetName` - The restored PVC names use the target VM name as a prefix: `-`. - `RandomizeNames` - The system generates the restored PVC names randomly: `restore--`. - `InPlace` - The restored PVCs overwrite the original PVCs. The system deletes the original PVCs if they exist and creates new PVCs with the same names. This is the default setting. - Optional: To control how restored persistent volume claims (PVCs) are named, you can set the `volumeRestorePolicy` parameter to one of the following values: - `PrefixTargetName` - The restored PVC names use the target VM name as a prefix: `-`. This is the default setting. - `RandomizeNames` - The restored PVC names are randomly generated: `restore--`. - `InPlace` - The restored PVCs overwrite the original PVCs. The original PVCs are deleted if they exist, and new PVCs are created with the same names. **Procedure** 1. Create a YAML file to define a `VirtualMachineRestore` object that specifies the name of the VM you want to restore and the name of the snapshot to be used as the source as in the following example: ```yaml apiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineRestore metadata: name: spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: virtualMachineSnapshotName: volumeRestorePolicy: PrefixTargetName ``` Where: - `volumeRestorePolicy`: Optional. The volume restore policy determines how restored PVCs are named. Valid values are `PrefixTargetName` (default), `RandomizeNames`, or `InPlace`. 2. Optional: To customize the names, labels, and annotations of individual restored persistent volume claims (PVCs), add the `volumeRestoreOverrides` parameter to the YAML file: ```yaml apiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineRestore metadata: name: spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: virtualMachineSnapshotName: volumeRestoreOverrides: - volumeName: restoreName: labels: custom-label: annotations: custom-annotation: ``` Where: - `volumeName`: Required. The name of the volume from the snapshot to customize. - `restoreName`: Optional. The custom name for the restored PVC. If not specified, the PVC name is determined by the `volumeRestorePolicy` setting. - `labels`: Optional. Custom labels to add to the restored PVC. These labels are merged with any existing labels from the source PVC. - `annotations`: Optional. Custom annotations to add to the restored PVC. These annotations are merged with any existing annotations from the source PVC. 3. Create the `VirtualMachineRestore` object: ```terminal $ oc create -f .yaml ``` The snapshot controller updates the status fields of the `VirtualMachineRestore` object and replaces the existing VM configuration with the snapshot content. **Verification** - Verify that the VM is restored to the previous state represented by the snapshot and that the `status.complete` flag is set to `true`: ```terminal $ oc get vmrestore ``` Example output: ```yaml apiVersion: snapshot.kubevirt.io/v1beta1 kind: VirtualMachineRestore metadata: creationTimestamp: "2020-09-30T14:46:27Z" generation: 5 name: my-vmrestore namespace: default ownerReferences: - apiVersion: kubevirt.io/v1 blockOwnerDeletion: true controller: true kind: VirtualMachine name: my-vm uid: 355897f3-73a0-4ec4-83d3-3c2df9486f4f resourceVersion: "5512" uid: 71c679a8-136e-46b0-b9b5-f57175a6a041 spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm virtualMachineSnapshotName: my-vmsnapshot status: complete: true conditions: - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "False" type: Progressing - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "True" type: Ready deletedDataVolumes: - test-dv1 restoreTime: "2020-09-30T14:46:28Z" restores: - dataVolumeName: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 persistentVolumeClaim: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 volumeName: datavolumedisk1 volumeSnapshotName: vmsnapshot-28eedf08-5d6a-42c1-969c-2eda58e2a78d-volume-datavolumedisk1 ``` > [!NOTE] > If the `Progressing` condition has `status: "True"`, the VM is still being restored. ## Deleting a snapshot by using the web console {#virt-deleting-vm-snapshot-web_virt-backup-restore-snapshots} You can delete an existing virtual machine (VM) snapshot by using the web console. **Procedure** 1. Navigate to **Virtualization** → **VirtualMachines** in the web console. 2. Select a VM to open the **VirtualMachine details** page. 3. Click the **Snapshots** tab to view a list of snapshots associated with the VM. 4. Click the Options menu ![](/openshift-docs-markdown/images/kebab.png "Options menu") beside a snapshot and select **Delete snapshot**. 5. Click **Delete**. ## Deleting a virtual machine snapshot in the CLI {#virt-deleting-vm-snapshot-cli_virt-backup-restore-snapshots} You can delete an existing virtual machine (VM) snapshot by deleting the appropriate `VirtualMachineSnapshot` object. **Prerequisites** - Install the OpenShift CLI (`oc`). **Procedure** - Delete the `VirtualMachineSnapshot` object: ```terminal $ oc delete vmsnapshot ``` The snapshot controller deletes the `VirtualMachineSnapshot` along with the associated `VirtualMachineSnapshotContent` object. **Verification** - Verify that the snapshot is deleted and no longer attached to this VM: ```terminal $ oc get vmsnapshot ``` ## Additional resources {#_additional_resources ._additional-resources-snapshots} - [CSI Volume Snapshots](/openshift-docs-markdown/storage/container_storage_interface/persistent-storage-csi-snapshots#persistent-storage-csi-snapshots)