Craig McClanahan
|
Posted: September 17, 2009 10:23 by Craig McClanahan
|
|
The current Cloud API specification has only limited information on backups of VMs. The purpose of this proposal is to flesh out the semantics related to this topic, as follows: * Creation of a backup (via a POST to the URI from the "back_up" field of a VM resource) accepts a Backup resource with (at a minimum) name and type fields. Valid values for "type" will be defined by the service provider. * The Backup resource must respond to a GET request to refresh the representation, and to a DELETE request to delete this backup, as do other resources defined in the API. * The Backup resource representation will include a "restore" URI, to which the client may send a POST to cause the VM that this backup was created from to be restored based on the contents of this backup. Craig |
Proposal: Flesh Out Lifecycle of Backups
29 topics, 131 posts
» Share this
Replies: 4 - Last Post: November 24, 2009 15:24
by: FastGeert
by: FastGeert
showing 1 - 5 of 5
Tim Bray
|
Posted: September 18, 2009 19:16 by Tim Bray
|
|
Yes, there are clearly missing semantics and this would be a useful addition. Having a field ("type") that is both required and has a value space specified per implementation is a recipe for zero interoperability. Thus, this should be optional, right? |
|
Craig McClanahan
|
Posted: September 24, 2009 20:55 by Craig McClanahan
|
|
> Having a field ("type") that is both required and has a value space specified per implementation > is a recipe for zero interoperability. Thus, this should be optional, right? No, it is more a recognition that different service providers will offer different flavors of backups (running VM state only, running VM state plus disks, etc.), and the API should provide a place to identify the desired flavor, without having to go outside the standard set of fields. I do agree that it should be optional, for the case where a service provider only one flavor or to select the default flavor that is most commonly used. |
FastGeert
|
Posted: November 24, 2009 15:24 by FastGeert
|
|
This does not cover incremental backups, which are very lightweight, only storing the diffs in a vm since a previous backup. Thus needing a starting point (one of the previous backups). We also plan to implement backup policies. In these policies backups will have retention periods. How could this be covered in the API ? Geert |
Replies: 4 - Last Post: November 24, 2009 15:24
by: FastGeert
by: FastGeert
