Add backup id to volume’s metadata

Problem description

Currently, the end user can see the source (source by snapshot or image etc.) from the new volume created. But when the end user has restored a backup volume, in the volume show response, we cannot see its source. This can cause a lot of confusion for end users.

Use Cases

As an end user, I would like to know the restored volume comes from which backup resource.

Proposed change

  • Add the property src_backup_id to the volume’s metadata, to record from which backup the new volume was created from. When restoring from a chain of incremental backups, src_backup_id is set to the last incremental backup used for the restore.

Once added to the volume metadata, the src_backup_id will appear on any API response that displays volume metadata:

  • the volume-show response (GET /v3/{project_id}/volumes/{volume_id})

  • the volume-list-detail response (GET /v3/{project_id}/volumes/detail)

  • the volume-metadata-show response (GET /v3/{project_id}/volumes/{volume_id}/metadata)

  • the volume-metadata-show-key response, only if the key is src_backup_id (GET /v3/{project_id}/volumes/{volume_id}/metadata/{key})

Vendor-specific changes




Data model impact


REST API impact

None. The volume-show, volume-list-detail, and volume-metadata-show responses are currently defined to contain a metadata element that is either JSON null or a JSON object consisting of a list of key/value pairs. The src_backup_id will appear in this list for appropriate volumes, but this respects the current API and does not require a new microversion.

Security impact


Notifications impact


Other end user impact


Performance Impact


Other deployer impact


Developer impact




Xuan Yandong

Work Items

  • Add src_backup_id to the volume metadata




  • Add related unit tests

  • Add related functional test

  • Add tempest tests

Documentation Impact

Release note should point out that since this is stored in the volume metadata, it can be modified or removed by end users, so operators should not rely upon it being present for administrative or auditing purposes.

Add a similar note somewhere in the admin docs, probably a page about volume metadata written by Cinder (which may not currently exist). In addition to reminding admins that end users can overwrite volume metadata, should explain how to read the src_backup_id (particularly the part about what id is used when restoring from incremental backups).