LifeCycle
Basically an internal step, designed to take the YAML configuration files into Capistrano so that it’s at least possible that people don’t have to understand Capistrano to configure a Blanket backup.
The prep step is to prepare a single file to be transferred to the sink. Some sources (like Confluence) generate files themselves, so this step is moot. Other sources are suited to special options (e.g. MySQL and SVN). But a generic sink could be very flexible using this step. It could tar all the files in a directory, run a command remotely and save the results to a file to be backed up, etc.
Pretty unsexy. The download stage downloads the remote file to the blanket directory so that it can be uploaded without having the AWS gems installed remotely. (After all, we can’t always pick our own environments, can we?)
There should be some capability to rotate the backups based on some flexible dating scheme. This should come before the cleanups phase. Why not have this on the source side? It may be useful to have some dated, on-site backups to ensure timely retrieval for those who can afford the disk space.
Cleanups have been conceived but not tested. Confluence will definitely need one, and other sources should want to clean up after themselves, as well.
See the same entry under Sources
So far, the sinks just have this step, to upload the file to the given backup sink.