Chapter 3. Using the Block Storage backup service

To back up a volume, use the cinder backup-create command. By default, this command creates a full backup of the volume. If the volume has existing backups, you can choose to create an incremental backup instead (see Section 2.4.1.2, “Create an Incremental Volume Backup” for details.)

You can create backups of volumes you have access to. This means that users with administrative privileges can back up any volume, regardless of owner. For more information, see Section 3.1.2, “Creating a volume backup as an admin”.

Users with administrative privileges (such as the default admin account) can back up any volume managed by OpenStack. When an admin backs up a volume owned by a non-admin user, the backup is hidden from the volume owner by default.

As an admin, you can still back up a volume and make the backup available to a specific tenant. To do so, run:

# cinder --os-auth-url _KEYSTONEURL_ --os-tenant-name _TENANTNAME_ --os-username _USERNAME_ --os-password _PASSWD_ backup-create _VOLUME_

Where:

You can also export and store the volume backup’s metadata. This allows you to restore the volume backup, even if the Block Storage database suffers a catastrophic loss.

To do so, run:

# cinder backup-export _BACKUPID_

Where BACKUPID is the ID or name of the volume backup. For example,

+----------------+------------------------------------------+
|    Property    |                Value                     |
+----------------+------------------------------------------+
| backup_service |     cinder.backup.drivers.swift          |
|   backup_url   | eyJzdGF0dXMiOiAiYXZhaWxhYmxlIiwgIm9iam...|
|                | ...4NS02ZmY4MzBhZWYwNWUiLCAic2l6ZSI6IDF9 |
+----------------+------------------------------------------+

The volume backup metadata consists of the backup_service and backup_url values.

You can also use the cinder backup-create command to create a backup of an in-use volume by adding the --force option.

By using the --force option, you acknowledge that you are not quiescing the drive before performing the backup. Using this method creates a crash-consistent (but not application-consistent) backup. In other words, the backup will not have an awareness of which applications were running when the backup was performed. However, the data will be intact.

# cinder backup-create _VOLUME_ --incremental --force

When creating a backup from a snapshot, you can do a full backup or an incremental backup (by including the --incremental option). You must identify the volume ID associated with the snapshot.

Some backup features like incremental and data compression may impact performance. Incremental backups have a performance impact because all of the data in a volume must be read and checksummed for both the full and each incremental backup.

Data compression can be used with non-Ceph backends. Enabling data compression requires additional CPU power but uses less network bandwidth and storage space overall.

Multipathing configuration also impacts performance. If multiple volumes are attached without multipathing enabled, you might not be able to connect and might not be using the full network capabilities, which impacts performance.

You can use the advanced configuration options (see Appendix B, Advanced Block Storage backup configuration options) to enable or disable compression, define the number of processes, and add additional CPU resources.

By default, the cinder backup-create command creates a full backup of a volume. However, if the volume has existing backups, you can choose to create an incremental backup.

Incremental backups are fully supported on NFS and Object Storage (swift).

An incremental backup captures any changes to the volume since the last backup (full or incremental). Performing numerous, regular, full backups of a volume can become resource-intensive as the volume’s size increases over time. In this regard, incremental backups allow you to capture periodic changes to volumes while minimizing resource usage.

To create an incremental volume backup, use the --incremental option. As in:

# cinder backup-create _VOLUME_ --incremental

Replace VOLUME with the ID or Display Name of the volume you want to back up.

These steps create a new volume from a backup.

If you no longer need the backup, delete it:

# cinder backup-delete _BACKUP_ID_

If you need to restore a backed up volume to a volume of a particular type, you can use --volume to restore a backup to a specific volume:

# cinder backup-restore _BACKUP_ID --volume VOLUME_ID_

Typically, a Block Storage database loss prevents you from restoring a volume backup. This is because the Block Storage database contains metadata required by the volume backup service (openstack-cinder-backup). This metadata consists of backup_service and backup_url values, which you can export after creating the volume backup (as shown in Section 3.1.1, “Creating a full volume backup”).

If you exported and stored this metadata, then you can import it to a new Block Storage database (thereby allowing you to restore the volume backup).

To issue a backup restoration cancellation, alter its status to anything other than restoring. You can use the “error” state to avoid any confusion on whether the restore was successful or not or the value can be changed to “available.”

$ openstack volume backup set --state error BACKUP_ID

The backup cancelation is an asynchronous action, as the backup driver needs to detect the status change before cancelling the backup. A change to “available” in the destination volume status means that the cancellation has been completed.

One of the first steps in troubleshooting is to verify that the necessary services are available and to check the logs for additional clues. Section 1.2, “How do backups and restores work?” illustrates the key services and their interaction.

After you verify the status of the services, check the cinder-backup.log file. The Block Storage Backup service log is located in /var/log/containers/cinder]/cinder-backup.log.

Backups themselves are asynchronous. A relatively small number of static checks are performed upon receiving an API request. These checks include an invalid volume reference (missing) or a volume that is in-use or attached to an instance. The in-use case requires you to use the --force option.

If the API accepts the request, the backup will take place in the background. Usually the CLI will return immediately even if the backup has failed or is about to fail. The status of a backup can be queried using cinder’s backup API. If an error does occur, review the logs for the cause.

The Block Storage backup service is deployed with Pacemaker by default. By configuring virtual IP addresses, containers, services, and other features as resources in a cluster, Pacemaker makes sure that the defined set of OpenStack cluster resources are running and available. When a service or an entire node in a cluster fails, Pacemaker can restart the resource, take the node out of the cluster, or reboot the node. Requests to most of those services are done through HAProxy.

For information on using Pacemaker for troubleshooting, refer to the Using Pacemaker chapter of the Understanding Red Hat OpenStack Platform High Availability guide.