Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1093901

Summary:	[RFE][cinder]: Backup Support for Encrypted Volumes
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	openstack-cinder	Assignee:	Eric Harney <eharney>
Status:	CLOSED ERRATA	QA Contact:	nlevinki <nlevinki>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	eharney, markmc, scohen, yeylon, yrabl
Target Milestone:	Upstream M1	Keywords:	FutureFeature, OtherQA
Target Release:	7.0 (Kilo)
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/cinder/+spec/backup-support-for-encrypted-volumes
Whiteboard:	upstream_milestone_kilo-1 upstream_definition_approved upstream_status_implemented
Fixed In Version:	openstack-cinder-2015.1.0-2.el7ost	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-05 13:12:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description RHOS Integration 2014-05-03 04:06:30 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/cinder/+spec/backup-support-for-encrypted-volumes.

Description:

Encrypted volumes require backups to include a clone of the volume's encryption key UUID so that the encryption key is available when the backup is restored. Otherwise, backups of encrypted volumes are unusable since their data cannot be decrypted! This blueprint supports backing up encryption metadata using the approach created for the backup volume metadata support blueprint (see https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support) in the Icehouse patch https://review.openstack.org/#/c/51900/.

When an encrypted volume is backed up, a copy of the volume's encryption key UUID will be stored with the metadata of the volume. Using a copied encryption key UUID (copied through the key manager), instead of an exact duplicate of the volume's encryption key UUID, allows the source volume to be deleted and its encryption key UUID made invalid. This copied encryption key UUID will allow access to the key used to encrypt the source volume when the backup is restored.

When a backup of an encrypted volume is restored, the backup driver will only allow the restoration of the volume when the source volume's volume type is available, and the destination volume (if specified) is of the same volume type. This is because volume types are used to specify the different encryption parameters, such as key_size and cipher. If the source volume's volume type is no longer available, the backup restoration will fail. Likewise, if the specified destination volume is of a different volume type than the source volume, the backup restoration will fail. If a destination volume is not specified, and the source volume's volume type is still available, the created destination volume will become the volume type of the source volume.

Specification URL (additional information):

None

Comment 6 errata-xmlrpc 2015-08-05 13:12:04 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1548