Backup

A backup represents a set of volume snapshots.

Definitions:
A snapshot is completed if its status is "available".
A snapshot is committed if it has a tag "rs_backup:committed=true".
A snapshot belongs to a backup "X" if it has a tag "rs_backup:backup_id=X".
A snapshot is part of a backup with size "Y" if it has a tag "rs_backup:count=Y".
A snapshot's position in a backup is "Z" if it has a tag "rs_backup:position=Z".

Backups are of 3 types:
Perfect backup: A backup which is completed(all the snapshots are completed) and committed(all the snapshots are committed) and the number of snapshots it found is equal to the number in the "rs_backup:count=" tag on each of the snapshots.

Imperfect backup: A backup which is not committed or if the number of snapshots it found is not equal to the number in the "rs_backup:count=" tag on each of the snapshots.

Partial Perfect backup: A snapshot which is neither perfect nor imperfect.

An imperfect backup is picked up for cleanup only if there exists a perfect backup with a newer created_at timestamp. No constraints will be applied on such imperfect backups and all of them will be destroyed.

For all the perfect backups, the constraints of keep_last and dailies etc. will be applied.
The algorithm for choosing the perfect backups to keep is simple. It is the union of those set of backups if each of those conditions are applied independently. i.e backups_to_keep = backups_to_keep(keep_last) U backups_to_keep(dailies) U backups_to_keep(weeklies) U backups_to_keep(monthlies) U backups_to_keep(yearlies)

Hence, it is important to "commit" a backup to make it eligible for cleanup.

Content-Types

Content type

application/vnd.rightscale.backup

Relationships

self

Href of itself

Actions

restore

Restores a backup

Attributes

actions

 

committed

 

completed

 

created_at

 

description

 

from_master

 

lineage

 

links

 

name

 

volume_snapshot_count

 

volume_snapshots