Proposal: Flesh Out Lifecycle of Backups

» Back to forum topics
  5 posts   Feedicon  
Replies: 4 - Last Post: November 24, 2009 15:24
by: FastGeert
showing 1 - 5 of 5
 
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
 
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?
 
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.
 
Posted: September 20, 2009 17:50 by yadieet
Right, make it simple.
 
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