A backup represents a set of volume snapshots.
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 type
- Href of itself
- Restores a backup