Back Up a KVM Guest Stored on Exascale Volumes

6.9.3 Back Up a KVM Guest Stored on Exascale Volumes

Back up an Oracle Linux KVM guest whose virtual disks are stored on Exascale Direct Volumes (EDV).

This procedure describes a recommended approach for creating a crash-consistent backup of the guest.

The approach creates a point-in-time snapshot of the corresponding Exascale volume group, creates a persistent backup for each required volume, and preserves the guest XML definition on the guest configuration-files volume. The guest operating system and applications continue running while the snapshots are established.

Use the backup procedure described here with the corresponding recovery procedure at Recover a KVM Guest Stored on Exascale Volumes.

This procedure creates a crash-consistent recovery point. It does not create an application-consistent backup and does not cover non-EDV disks.

Before you begin:

Perform this procedure as an administrator (root) on the KVM host where the guest is located.
Ensure that you have a wallet for connecting to Exascale and sufficient privileges to manage the Exascale volumes that host the guest image files. Ask your Exascale administrator to provide the wallet and grant you sufficient privileges. See also Provision a User and Associated Wallet in Oracle Exadata Exascale User's Guide.

Identify the guest that you want to back up.
On the KVM host, list the guests:
```
# /opt/exadata_ovm/vm_maker --list-domains
```
Record the guest name and whether the guest is running.

Use the exact guest name returned by vm_maker as guest-name in every following command, file name, and backup path.
Identify the Exascale volumes used by the guest.
List the disk images associated with the guest:
```
# /opt/exadata_ovm/vm_maker --list --disk-image --domain guest-name --detail
```
For a guest using Exascale storage, the disk paths are displayed as /dev/exc/... devices. Record the Exascale volumes associated with the guest.

Also identify the host-mounted configuration-files volume, which contains various configuration files associated with the guest. Record the source device path (/dev/exc/...):
```
# findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /EXAVMIMAGES/GuestImages/guest-name
```
Save the guest XML definition and the mount options for the configuration-file volume.
Create a configuration backup directory inside the configuration-files volume:
```
# mkdir -p /EXAVMIMAGES/GuestImages/guest-name/configbackup
```
Save the guest XML definition:
```
# virsh dumpxml guest-name --inactive > /EXAVMIMAGES/GuestImages/guest-name/configbackup/guest-name.xml
```
Caution:

Ensure that you include the --inactive option to avoid potential problems during recovery.

Save the mount options for the configuration-file volume:
```
# grep -F '/EXAVMIMAGES/GuestImages/guest-name' /etc/fstab > /EXAVMIMAGES/GuestImages/guest-name/configbackup/guest-name.fstab
```
Verify that the newly created files exist and contain the expected details:
```
# more /EXAVMIMAGES/GuestImages/guest-name/configbackup/*
```
The configuration-files volume now contains a backup of the guest’s XML definition and a file specifying the mount options for the volume. The volume is backed up later in this procedure along with the guest image volumes.
Identify the Exascale volume group that contains the guest volumes.
Connect to the Exascale command line interface (ESCLI) using your Exascale wallet:
```
# escli --wallet wallet-location
```
In ESCLI, list the volume groups:
```
@> lsvolumegroup --attributes id,name,state,volumes
```
Guest volume groups use a name with the following format:
```
sysvolgrp_short-guest-name
```
For example:
```
@> lsvolumegroup --filter name=sysvolgrp_exa01adm01vm01 --attributes id,name,state,volumes
```
Record the volume group ID and the exact group name returned by ESCLI.

If no volume group exists for the guest, create one using the expected name format, and add all Exascale volumes used by the guest to it.
Verify that the volume group contains all required guest volumes.
List the volumes in the volume group:
```
@> lsvolume --filter volumeGroup=volume-group-ID --attributes id,name,size,state,vault
```
Compare the returned volumes with the Exascale devices identified in step 2.

Verify that:
- All volumes required by the guest are present.
- The guest configuration-files volume is present.
- No extra volumes are present.
- All required volumes are in the AVAILABLE state.
Note:

Do not continue until you have verified that the volume group contains the exact set of Exascale volumes required to recover the guest. If any volumes are missing or extraneous, add or remove them as appropriate.
Determine the Exascale backup location.
Identify an Exascale vault where you want to store the backup. For example, @backupvault.

Choose a unique destination path for the backup. Use a path that contains the guest name and backup timestamp, such as:
```
@backupvault/guest-backups/guest-name/backup-timestamp/
```
For example:
```
@backupvault/guest-backups/exa01adm01vm01.example.com/20260826T120000Z/
```
Use the same destination path for every volume backup in this backup set.
Create a snapshot of the Exascale volume group.
In ESCLI, run:
```
@> mkvolumegroupsnapshot volume-group-ID
```
Record the volume group snapshot ID returned by the command.

The operation creates a point-in-time-consistent set of volume snapshots for the member volumes in the volume group.
Gather information about the individual volume snapshots and corresponding source volumes.
1. List all snapshots associated with the volume group snapshot:
```
@> lsvolumesnapshot --filter volumeGroupSnapshot=volume-group-snapshot-ID --attributes id,volume,state
```
  Verify that:
  - A snapshot exists for every expected guest volume.
  - Each snapshot is in the AVAILABLE state.
  Record each volume snapshot ID and its corresponding source volume ID.
2. For each source volume, record the volume ID and name:
```
@> lsvolume source-volume-ID --attributes id,name
```
  You will use this information to name the corresponding volume backup.
Create a persistent Exascale backup for each volume snapshot.
For every volume snapshot identified in the previous step, run the mkvolumebackup command and specify:
- The volume snapshot ID, identified in the previous step.
- The backup destination, which you chose earlier.
- The volume backup name. Use the source volume ID and name recorded in the previous step as follows:
```
volume-name_volume-ID
```
  For example:
```
exa01adm01vm01_sys_vol0019_acb70712ce824e8fbfef0205a05dd5fc
```
  The recovery procedure uses this value to identify the original volume name and ID.
For example:
```
@> mkvolumebackup --attributes volumeSnapshot=volume-snapshot-ID,destination=@backupvault/guest-backups/guest-name/backup-timestamp/,name=volume-name_volume-ID
```
Repeat the command for every volume snapshot associated with the volume group snapshot.

Record every volume backup ID returned by mkvolumebackup.
Monitor each volume backup until completion.
Run:
```
@> lsvolumebackup --filter destination=@backupvault/guest-backups/guest-name/backup-timestamp/* --attributes id,name,state,progress
```
A backup that is still being created shows state=CREATING.

A successfully completed backup reports state=AVAILABLE.

Note:

Do not proceed until every required persistent volume backup is in the AVAILABLE state.
Verify the complete guest backup set.
List the contents of the Exascale backup location:
```
@> ls -l @backupvault/guest-backups/guest-name/backup-timestamp/
```
Verify that the location contains one persistent volume backup for every required guest volume.

Verify the volume backups:
```
@> lsvolumebackup --filter destination=@backupvault/guest-backups/guest-name/backup-timestamp/* --detail
```
For each volume backup, verify that:
- The volume backup name attribute contains the name and ID of the corresponding source volume.
- The volume attribute matches the corresponding source volume ID.
- The backup is in the AVAILABLE state.
The guest backup set is complete only when every required volume has a corresponding volume backup in the AVAILABLE state. Do not proceed until you verify that the backup set is complete.
Remove the temporary volume snapshots.
List the volume snapshots associated with the volume group snapshot:
```
@> lsvolumesnapshot --filter volumeGroupSnapshot=volume-group-snapshot-ID
```
Remove each volume snapshot:
```
@> rmvolumesnapshot volume-snapshot-ID
```
Repeat the command for every volume snapshot associated with the volume group snapshot.

After removal, verify that the snapshots no longer exist:
```
@> lsvolumesnapshot --filter volumeGroupSnapshot=volume-group-snapshot-ID
```
Note:

If removal of a temporary snapshot fails after the corresponding persistent backup is available, retain the completed backup and resolve the snapshot cleanup problem separately.

The Exascale backup location contains persistent backups of all Exascale volumes required by the guest. The guest XML definition is stored in the backup of the guest configuration-files volume. Together, these artifacts form the guest backup set.

Related Topics

Parent topic: Backing up the KVM host and Guests