Rubber comes "out of the can" with some excellent backup capabilities.

By default it will perform automatic backups once every 3 hours and will keep them stored along with your instance data. If you have "important but not earthshakingly important" data, this might be just fine and not need any fiddling around with.

These "default" backups can be found on your instance in a directory very near the root of the instance at: /mnt/db_backups

(note there are other interesting things in "/mnt", like your database directory (such as "postgresql") and the "myapplicationname-production" directory where your application lives)

The stuff that Rubber sets up to do the backup (a cron job that runs continuously on the server) also takes care of throwing away old backups. Specifically, it keeps the past week's worth of these every-three-hours backups and tosses everything older than that.

There are some reasons that you might (probably) want to keep backups somewhere else:

1. Basic sanity regarding backups -- keep them as "far away" from the source file as possible
2. There aren't many non-command-line tools that would help you look at and maintain and use backups that are right there on your instance. There are other places to put the backups where they can be more useful
3. If your instance goes away, your backups go away! If you use the rubber command "cap rubber destroy", then pffffft, both your main database and your backups are all toast and you can't get them back. Same thing if you inadvertently/stupidly/clumsily delete the instance in the Amazon EC2 dashboard. Pfffft. All gone.

Since there are plenty of good reasons to "store the backups someplace else", Rubber also provides a very easy way to do that. It assumes that the same Amazon account where you have your EC2 happening also has S3 storage enabled. S3 storage is super cheap and while it isn't guaranteed storage, it has a crazy high reliability rating and is almost certainly sitting on a different hard-drive connected to a different CPU (possibly even in a different building or at a different data center) than your EC2 instance. Further, you would have to stupidly delete two different things in two different parts of the Amazon GUI interface to loose everything, and there simply isn't anything provided in Rubber commands that would wipe out your S3 storage. It's pretty much stupid-proof.

Enabling this "extra copy" of your automated backups couldn't be easier. Look in the Rubber.yml file for a commented out line like this: # backup_bucket: "#{app_name}-backups"

Just un-comentify that one line and you will now have a new "bucket" show up in your S3 storage with the obvious name of "yourappname-backups". The same "every-three-hours" and limited to the past week rules apply to the backups kept there by Rubber.

There is a rubber/capistrano command to then use one of these backups to restore you production db from the S3-based backup file of your choice. You would need to go to your S3 storage and capture the name of an appropriately timed backup file (something like "production_dump_2014-01-12_12-00.sql.gz") and then go to command line from your app's directory enter: cap rubber:util:restore_cloud production_dump_2014-01-12_12-00.sql.gz