Comment 1 for bug 1137908

For normal metadata, this can be handled by storing the metadata with the backup in swift during creation, and restoring during a restore operation. The metadata can either be added to the existing backup metadata file or in a separate file. I don't think there is any good reason not to add it to the existing backup metadata file. There may be some metadata that should be excluded from this process if it doesn't apply to anything but the original volume.

For the glance metadata, the solution is not as trivial. The glance metadata, particularly the billing metadata, needs to be stored in a way that it cannot be tampered with by the user (since some of the metadata relates to licensing and so on). Volume backups are stored in user's space in swift and can thus be modified by the user, precluding us from using the same solution as for normal metadata. There are a number of potential alternatives detailed below,

1. If possible with keystone, during backup the glance metadata could be signed with a credential associated with the openstack administrator and then written with the backup in the normal way (either to the existing backup metadata file or to a separate file). On restore, the signature could be verified and if the metadata has been found to have been tampered with, either the restore fails or the glance metadata is omitted from the restore.

2. The backup process could be modified to backup the glance metadata to a separate area of swift, inaccessible to all but administrative users. During the restore, the data could be re-read from there.

3. During a restore, the glance metadata for the original volume could be re-read from the database for the original volume and copied/associated with the new volume. This obviously has the limitation that the glance metadata is not "backed up" outside of the volumes database and will thus be lost in the event of a catastrophic failure of the cluster (which the redundant backup on swift would hopefully survive). Is that a problem or is the glance metadata inherently tied to a single openstack system anyway?

Approaches 1. and 2. may also be insufficient to handle a restore to an entirely new openstack system unless sufficient data is backed up to allow administrator credentials to be restored/reconstructed on the new system (although again 1 has the benefit that digital signature verification could be performed with a copy of the administrator's public key, which could be stored with each backup).