Chapter 1. Overview of the Block Storage backup service

A volume backup is a persistent copy of the contents of a volume. Volume backups are typically created as object stores, and are managed through the OpenStack Object Storage service (swift) by default. You can use Red Hat Ceph and NFS as alternative back ends for backups.

When you create a volume backup, all of the backup metadata is stored in the Block Storage service database. The cinder-backup service uses this metadata when it restores a volume from the backup. This means that when you perform a recovery from a catastrophic database loss, you must restore the Block Storage service database first before you restore any volumes from backups, provided that the original volume backup metadata of the Block Storage service database is intact. If you want to configure only a subset of volume backups to survive a catastrophic database loss, you can also export the backup metadata. You can then re-import the metadata to the Block Storage database by using the REST API or the cinder client, and restore the volume backup as normal.

Volume backups are different from snapshots. Backups preserve the data contained in the volume, and snapshots preserve the state of a volume at a specific point in time. You cannot delete a volume if it has existing snapshots. Volume backups prevent data loss, whereas snapshots facilitate cloning. For this reason, snapshot back ends are typically colocated with volume back ends in order to minimize latency during cloning. By contrast, the backup repository is typically located separately from the back ends, either on a different node or different physical storage. This protects the backup repository from any damage that might occur to the volume back end.

For more information about volume snapshots, see "Create, Use, or Delete Volume Snapshots" in the Storage Guide.

The following subsections, 1.2.1 and 1.2.2, illustrate the workflows for backups and restores.

1.2.1. Volume backup workflow

When the Block Storage backup service performs a back up, it receives a request from the cinder API to back up a targeted volume. The backup service completes the request and stores the content on the back end.

The following diagram illustrates how the request interacts with the Block Storage (cinder) services to perform the backup.

1. The client issues a request to back up a Block Storage volume by invoking the cinder API.
2. The cinder API service receives the request from HAProxy and validates the request, the user credentials, and other information.
3. Creates the backup record in the SQL database.
4. Makes an asynchronous RPC call to the cinder-backup service via AMQP to back up the volume.
5. Returns current backup record, with an ID, to the API caller.
6. An RPC create message arrives on one of the backup services.
7. The cinder-backup service performs a synchronous RPC call to get_backup_device.
8. The cinder-volume service ensures that the correct device is returned to the caller. Normally, it is the same volume, but if the volume is in use, the service returns a temporary cloned volume or a temporary snapshot, depending on the configuration.
9. The cinder-backup service issues another synchronous RPC call to cinder-volume to expose the source device.
10. The cinder-volume service exports and maps the source device, either a volume or snapshot, and returns the appropriate connection information.
11. The cinder-backup service attaches source volume by using connection information.
12. The cinder-backup service calls the backup driver, with the device already attached, which begins the data transfer to the backup destination.
13. The volume is detached from the backup host.
14. The cinder-backup service issues a synchronous RPC call to cinder-volume to disconnect the source device.
15. The cinder-volume service unmaps and removes the export for the device.
16. If a temporary volume or temporary snapshot was created, cinder-backup calls cinder-volume to remove it.
17. The cinder-volume service removes the temporary volume.
18. When the backup is completed, the backup record is updated in the database.

1.2.2. Volume restore workflow

The following diagram illustrates the steps that occur when a user requests to restore a Block Storage service (cinder) backup.

1. The client issues a request to restore a Block Storage backup by invoking the CinderREST API.
2. The cinder API receives the request from HAProxy and validates the request, the user credentials, and other information.
3. If the request does not contain an existing volume as the destination, the API makes an asynchronous RPC call to create a new volume and polls the status of the volume until it becomes available.
4. The cinder-scheduler selects a volume service and makes the RPC call to create the volume.
5. Selected cinder-volume service creates the volume.
6. When cinder-api detects that the volume is available, the backup record is created in the database.
7. Makes an asynchronous RPC call to the backup service via AMQP to restore the backup.
8. Returns the current volume ID, backup ID, and volume name to the API caller.
9. An RPC create message arrives on one of the backup services.
10. The cinder-backup service performs a synchronous RPC call to cinder-volume to expose the destination volume.
11. The cinder-volume service exports and maps the destination volume and returns the appropriate connection information.
12. The cinder-backup service attaches source volume by using connection information.
13. The cinder-backup service calls the driver, with the device already attached, which begins the data restoration to the volume destination.
14. The volume is detached from the backup host.
15. The cinder-backup service issues a synchronous RPC call to cinder-volume to disconnect the source device.
16. The cinder-volume service unmaps and removes the export for the device.
17. When the backup is completed, the backup record is updated in the database.

The Google Cloud Storage driver is the only cloud driver that is supported by the Block Storage backup service. By default, the Google Cloud Storage driver uses the least expensive storage solution, Nearline, for this type of backup.

Configure the backup service to optimize performance. For example, if you create backups from Europe, change the backup region to Europe. If you do not change the backup region from the default, US, the performance might be slower due to the geographical distance between the two regions.

The following table lists the benefits and limitations of cloud storage and local storage based on the situation.