Difference between revisions of "Refactor Cinder Backup To Use Snapshots"
(Created page with "Backups can be more efficient, and not require any lien on the volume being backed up, if they are based on a snapshot rather than a volume. This can be enabled by making sna...") |
|||
| Line 1: | Line 1: | ||
Backups can be more efficient, and not require any lien on the volume being backed up, if they are based on a snapshot rather than a volume. | Backups can be more efficient, and not require any lien on the volume being backed up, if they are based on a snapshot rather than a volume. | ||
| − | This can be enabled by making snapshots full objects. See | + | This can be enabled by making snapshots full objects. See [[Snapshot_as_full_objects]] which is part of the [[CERSS]] initiative. |
The steps to backing up a Volume would be: | The steps to backing up a Volume would be: | ||
Latest revision as of 20:18, 18 November 2013
Backups can be more efficient, and not require any lien on the volume being backed up, if they are based on a snapshot rather than a volume.
This can be enabled by making snapshots full objects. See Snapshot_as_full_objects which is part of the CERSS initiative.
The steps to backing up a Volume would be:
- Create an anonymous snapshot.
- Put Backup objects from the anonymous snapshot.
- Delete the anonymous snapshot.
Requests would also be allowed to use an existing snapshot and to create a named snapshot which would then be backed up.
As with snapshot replication, the Volume Driver will have the option to instruct the storage backend to directly post the backup to the object storage system without having to transfer the payload through the cinder node.
