Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 3. Using the Block Storage backup service

This chapter explains how to use the Block Storage backup service to perform full or incremental backups, how to restore a backup to a volume, and basic troubleshooting tips.

3.1. Full backups
Copiar enlace

3.1.1. Creating a full volume backup
Copiar enlace

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 create an incremental backup instead. For information about creating an incremental backup, see Section 2.4.1.2, “Create an Incremental Volume Backup” in the Storage Guide.

You can create backups of volumes to which you have access. 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”.

Procedure

  1. View the ID or Display Name of the volume you want to back up: 

    # cinder list
    Copy to Clipboard Toggle word wrap

  2. Back up the volume: 

    # cinder backup-create --name <full_backup_name> _VOLUME_
    Copy to Clipboard Toggle word wrap

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

      +-----------+--------------------------------------+
  |  Property |                Value                 |
  +-----------+--------------------------------------+
  |     id    | e9d15fc7-eeae-4ca4-aa72-d52536dc551d |
  |    name   |                 None                 |
  | volume_id | 5f75430a-abff-4cc7-b74e-f808234fa6c5 |
  +-----------+--------------------------------------+
    Copy to Clipboard Toggle word wrap

    The volume_id of the resulting backup is identical to the ID of the source volume.

  3. Verify that the volume backup is complete: 

    # cinder backup-list
    Copy to Clipboard Toggle word wrap

    The volume backup is complete when the Status of the backup entry is available.

3.1.2. Creating a volume backup as an admin
Copiar enlace

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.

Procedure

To back up a volume and make the backup available to a specific tenant: 

# cinder --os-tenant-name _TENANTNAME_ backup-create _VOLUME_
Copy to Clipboard Toggle word wrap

Where:

  • TENANTNAME is the name of the tenant where you want to make the backup available.
  • VOLUME is the name or ID of the volume you want to back up.

When performing this operation, the size of the backup counts against the quota of TENANTNAME rather than the admin’s tenant.

3.1.3. Exporting backup metadata from a volume
Copiar enlace

You can export and store the backup metadata from a volume. Exporting and storing the backup metadata from a volume allows you to restore a volume even if the Block Storage database suffers a catastrophic loss. This is useful when you require full backups of only a small subset of volumes.

When you back up a volume and export its metadata, you can restore the volume on a different Block Storage database or cloud service. Volume encryption is retained in the backup metadata if you specify UUID encryption during volume creation. The restored, encrypted volume is then accessible with your credentials.

Procedure

Run the following command to export and store backup metadata: 

# cinder backup-export _BACKUPID_
Copy to Clipboard Toggle word wrap

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 |
+----------------+------------------------------------------+
Copy to Clipboard Toggle word wrap

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

3.1.4. Backing up an in-use volume
Copiar enlace

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

Note

The --force option relies on Block Storage back end snapshot support and should be supported by most drivers. You can verify snapshot support by checking the documentation for the back end you are using.

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.

Procedure

To create a backup of an in-use volume, run: 

# cinder backup-create _VOLUME_ --incremental --force
Copy to Clipboard Toggle word wrap

3.1.5. Backing up a snapshot
Copiar enlace

You can create a full backup from a snapshot by using the volume ID that is associated with the snapshot.

Procedure

  1. Locate the snapshot ID of the snapshot to back up using cinder snapshot list. 

    # cinder snapshot-list --volume-id _VOLUME_ID_
    Copy to Clipboard Toggle word wrap

  2. If the snapshot is named, you can use this example to locate the ID: 

    # cinder snapshot-show _SNAPSHOT_NAME_
    Copy to Clipboard Toggle word wrap

  3. Create the backup of a snapshot: 

    # cinder backup-create _VOLUME_ --snapshot-id=_SNAPSHOT_ID_
    Copy to Clipboard Toggle word wrap
    Note

    Snapshot-based backups of NFS volumes fail when you use the --snapshot-id option. This is a known issue.

3.2. Incremental backups
Copiar enlace

The Block Storage backup service provides the option of performing incremental backups.

3.2.1. Performance considerations
Copiar enlace

Some backup features, such as 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 backup 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 to the volumes or experience full network capabilities, which impacts performance.

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

3.2.1.1. Backup from a snapshot impact
Copiar enlace

Some back ends support creating a backup from a snapshot. A driver that supports this feature can directly attach a snapshot to a volume, which is faster than cloning the snapshot into a volume. In general, this feature can affect performance because of the extra step of creating the volume from a snapshot.

3.2.2. Performing incremental backups
Copiar enlace

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, Object Storage (swift), and Red Hat Ceph Storage backup repositories. Ceph backups currently ignore the --incremental option. Ceph backups attempt to perform incremental backups when the source is a Ceph volume, therefore it is not possible to perform multiple full backups.

Note

Incremental Ceph backups cannot be performed for non-Ceph volumes.

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. Incremental backups allow you to capture periodic changes to volumes while minimizing resource usage.

Procedure

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

# cinder backup-create --name <incremental_backup_name> --incremental _VOLUME_
Copy to Clipboard Toggle word wrap

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

Note

You cannot delete a full backup if it already has an incremental backup. If a full backup has multiple incremental backups, you can only delete the latest one.

3.3. Canceling a backup
Copiar enlace

To cancel a backup, an admin must request a force delete on the backup: 

# cinder backup-delete --force BACKUP ID
Copy to Clipboard Toggle word wrap

Even if the backup is immediately deleted and no longer appears in the listings, the cancellation operation may still be running. Check the status of the source resource to verify when the status is no longer “backing-up”.

Note

Before Red Hat OpenStack Platform version 12, the “backing-up” status was stored in the volume, even when backing up a snapshot. Therefore, when backing up a snapshot, any delete operation on the snapshot that followed a cancellation could result in an error if the snapshot was still mapped. In Red Hat OpenStack Platform version 13 and later, ongoing restoration operations can be canceled on any of the supported backup drivers.

3.4. Viewing and modifying the backup quota of a tenant
Copiar enlace

You can use the dashboard to modify tenant storage quotas, for example, the number of volumes, volume storage, snapshots, or other operational limits that a tenant can have. However, you cannot modify backup quotas through the dashboard.

You must use the command-line interface to modify backup quotas by using the cinder quota-update command.

Procedure

  1. To view the storage quotas of a specific tenant (TENANT_ID), run: 

    # cinder quota-show TENANT_ID
    Copy to Clipboard Toggle word wrap

  2. To update the maximum number of backups (MAXNUM) that can be created in a specific tenant, run: 

    # cinder quota-update --backups MAXNUM TENANT_ID
    Copy to Clipboard Toggle word wrap

  3. To update the maximum total size of all backups (MAXGB) within a specific tenant, run: 

    # cinder quota-update --backup-gigabytes MAXGB TENANT_ID
    Copy to Clipboard Toggle word wrap

  4. To view the storage quota usage of a specific tenant, run: 

    # cinder quota-usage TENANT_ID
    Copy to Clipboard Toggle word wrap

3.5. Restoring from backups
Copiar enlace

3.5.1. Restoring a volume from a backup
Copiar enlace

These steps create a new volume from a backup.

Procedure

  1. Find the ID of the volume backup you want to use: 

    # cinder backup-list
    Copy to Clipboard Toggle word wrap

    The Volume ID must match the ID of the volume you want to restore.

  2. Restore the volume backup: 

    # cinder backup-restore _BACKUP_ID_
    Copy to Clipboard Toggle word wrap

    Where BACKUP_ID is the ID of the volume backup you want to use.

  3. If you no longer need the backup, delete it: 

    # cinder backup-delete _BACKUP_ID_
    Copy to Clipboard Toggle word wrap

  4. If you must restore a backed up volume to a volume of a particular type, use the --volume option to restore a backup to a specific volume: 

    # cinder backup-restore _BACKUP_ID --volume VOLUME_ID_
    Copy to Clipboard Toggle word wrap
    Note

    If you restore a volume from an encrypted backup, then the destination volume type must also be encrypted.

3.5.2. Restoring a volume after a Block Storage database loss
Copiar enlace

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. For more information, see Section 3.1.1, “Creating a full volume backup”.

If you exported and stored this metadata, you can import it to a new Block Storage database, which enables you to restore the volume backup.

Note

For incremental backups, you must import all exported data before you can restore one of the incremental backups.

Procedure

  1. As a user with administrative privileges, run: 

    # cinder backup-import _backup_service_ _backup_url_
    Copy to Clipboard Toggle word wrap

    Where backup_service and backup_url are from the metadata you exported. For example, using the exported metadata from Section 3.1.1, “Creating a full volume backup”: 

    # cinder backup-import cinder.backup.drivers.swift eyJzdGF0dXMi...c2l6ZSI6IDF9
+----------+--------------------------------------+
| Property |                Value                 |
+----------+--------------------------------------+
|    id    | 77951e2f-4aff-4365-8c64-f833802eaa43 |
|   name   |                 None                 |
+----------+--------------------------------------+
    Copy to Clipboard Toggle word wrap
  2. After the metadata is imported into the Block Storage service database, you can restore the volume as normal. For more information, see Section 3.5.1, “Restoring a volume from a backup”.

3.5.3. Canceling a restoration
Copiar enlace

Procedure

  1. To cancel the restoration of a backup, alter its status to anything other than restoring. You can use the error state to minimize confusion regarding whether the restore was successful or not. Alternatively, you can change the value to available. 

    $ openstack volume backup set --state error BACKUP_ID
    Copy to Clipboard Toggle word wrap
Note

Backup cancellation is an asynchronous action, because the backup driver must detect the status change before it cancels the backup. When the status changes to available in the destination volume, the cancellation is complete.

Note

This feature is not currently available on RBD backups.

Warning

If a restore operation is canceled after it starts, the destination volume is useless, because there is no way of knowing how much data, if any, was actually restored.

3.6. Troubleshooting
Copiar enlace

You can diagnosed many issues by verifying that services are available and by looking in log files for error messages.

Two scenarios account for many issues with the backup service:

  • When the cinder-backup service starts up, it connects to its configured back end and uses the back end as a target for backups. Problems with this connection can cause a service to be down.
  • When backups are requested, the backup service connects to the volume service and attaches the requested volume. You will not notice connection problems until backup time.

In either case, review the logs for error messages.

For more information about log locations and troubleshooting suggestions, see Logging, Monitoring and Troubleshooting Guide. Log files and services are listed in the Log Files for OpenStack Services section.

3.6.1. Verifying services
Copiar enlace

Verify that the necessary services are available and check the logs for error messages. Section 1.2, “How do backups and restores work?” illustrates the key services and their interaction.

Note

When troubleshooting an active/passive configuration, make sure to review the log files on the active controller node.

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.

Procedure

  1. Run cinder show on the volume to see if the volume is stored by the host: 

    # cinder show
    Copy to Clipboard Toggle word wrap

  2. Run cinder service-list to view running services: 

    # cinder service-list
+------------------+--------------------+------+---------+-------+----------------------------+-----------------+
| Binary           | Host               | Zone | Status  | State | Updated_at                 | Disabled Reason |
+------------------+--------------------+------+---------+-------+----------------------------+-----------------+
| cinder-backup    | hostgroup          | nova | enabled | up    | 2017-05-15T02:42:25.000000 | -               |
| cinder-scheduler | hostgroup          | nova | enabled | up    | 2017-05-15T02:42:25.000000 | -               |
| cinder-volume    | hostgroup@sas-pool | nova | enabled | down  | 2017-05-14T03:04:01.000000 | -               |
| cinder-volume    | hostgroup@ssd-pool | nova | enabled | down  | 2017-05-14T03:04:01.000000 | -               |
+------------------+--------------------+------+---------+-------+----------------------------+-----------------+
    Copy to Clipboard Toggle word wrap

  3. Run pcs resource to verify the controller on which the cinder backup resource is running: 

    $ pcs resource

openstack-cinder-volume (systemd:openstack-cinder-volume): Started controller-0
    Copy to Clipboard Toggle word wrap

3.6.2. Troubleshooting tips
Copiar enlace

Backups are asynchronous. The Block Storage backup service performs a small number of static checks upon receiving an API request, such as checking for 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.

Note

Using the --force option means that I/O will not be quiesced and the resulting volume image may be corrupt.

If the API accepts the request, the backup occurs in the background. The CLI returns immediately, even if the backup has failed or is about to fail. The status of a backup can be queried using the cinder backup API. If an error occurs, review the logs for the cause.

3.6.3. Pacemaker
Copiar enlace

By default, the Block Storage backup service is deployed with Pacemaker in active/passive mode. By configuring virtual IP addresses, containers, services, and other features as resources in a cluster, Pacemaker ensures 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 Managing high availability services with Pacemaker of the High Availability Deployment and Usage guide.

Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat