Chapter 1. Overview of the Red Hat OpenStack Platform 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. By default, they are managed through the OpenStack Object Storage service (swift). Optionally, you can configure Red Hat Ceph Storage 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 the metadata to restore a volume from the backup. When you recover data from catastrophic database loss, you must restore the Block Storage service database before restoring any volumes from backups. This recovery scenario presumes that the Block Storage service database is restored with all of the original volume backup metadata intact.

If you want to configure volume backups for only a subset of data, you must export the backup metadata for the volume. Volume metadata backups enable you to re-import the metadata to the Block Storage database, through 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 are used to prevent data los. Snapshots preserve the state of a volume at a specific point in time and are used to facilitate cloning. You cannot delete a volume if it has existing snapshots.

To minimize latency during cloning, snapshot back ends are typically co-located with volume back ends. In a typical enterprise deployment, a backup repository is located in a separate location from the volume back end, such as on a different node, physical storage, or geographical location. This practice protects the backup repository from 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.

Volume backups and restores have similar workflows.

1.2.1. Volume backup workflow

Copiar enlace

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

The following diagram illustrates how the request interacts with cinder services to perform the backup.

View larger image

1. The client issues a request to back up a cinder volume by invoking the cinder REST API.

2. The cinder API service receives the request from HAProxy and validates the request, user credentials, and so forth.

   1. Creates the backup record in the SQL database.
   2. Makes an asynchronous RPC call to the cinder-backup service via AMQP to back up the volume.
   3. Returns the current backup record, with an ID, to the API caller.
3. The RPC create message arrives on one of the backup services.
4. The cinder-backup service makes a synchronous RPC call to get_backup_device.
5. The cinder-volume service ensures 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 instead, depending on the configuration.
6. The cinder-backup service makes another synchronous RPC to cinder-volume to expose the source device.
7. The cinder-volume service exports and maps the source device (volume or snapshot) returning the appropriate connection information.
8. The cinder-backup service attaches source volume using connection information.
9. The cinder-backup service calls the backup driver with the device already attached, which begins the data transfer to the backup destination.
10. The volume is detached from the backup host.
11. The cinder-backup service makes a synchronous RPC to cinder-volume to disconnect the source device.
12. The cinder-volume service unmaps and removes the export from the device.
13. If a temporary volume or temporary snapshot was created, cinder-backup calls cinder-volume to remove it.
14. The cinder-volume service removes the temporary volume.
15. After the backup completed, the backup record is updated in the database.

1.2.2. Volume restore workflow

Copiar enlace

The following diagram illustrates the steps that occur when a user restores a Block Storage backup.

View larger image

1. The client issues a request to restore a cinder backup by invoking the CinderREST API.
2. The cinder API receives the request from HAProxy and validates the request, user credentials, and so forth.
3. If the request did 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. The selected cinder-volume service creates the volume.
6. After the cinder-api detects the available volume, the backup record is created in the database.
7. The cinder-api makes an asynchronous RPC call to the backup service via AMQP to restore the backup and returns the current volume ID, backup ID, and volume name to the API caller.
8. The RPC create message arrives on one of the backup services.
9. The cinder-backup service makes a synchronous RPC call to cinder-volume to expose the destination volume.
10. The cinder-volume service exports and maps the destination volume and returns the appropriate connection information.
11. The cinder-backup service attaches the source volume using connection information.
12. The cinder-backup service calls the driver with the device already attached, which begins the data restoration to the volume destination.
13. The volume is detached from the backup host.
14. The cinder-backup service issues a synchronous RPC to cinder-volume to disconnect the source device.
15. The cinder-volume service unmaps and removes the export from the device.
16. After the backup completes, the backup record is updated in the database.