AWS Backups

AWS Backups

(state of play 2017-04-27 for Amazon Web Services deployments)

Data in the Refinery application is separated into bulk file data, store on EBS, and application data and metadata, stored in RDS.

So backups are divided into two areas: RDS (database) and EBS (attached storage).

Both are backed up as snapshots. Snapshots (an EBS snapshot and an RDS snapshot) can be used when creating a stack to restore a previous state.

Coherence of snapshots

In AWS infrastructure, snapshots are a point in time and are not in general coordinated with the instance filesystem. This means that a snapshot is similar to unplugging a physical disk. The filesystem could be caught in an inconsistent state.

The current backup scheme is simple and does nothing to help with this problem. Most of the time it should be fine, but we recommend that prior to deleting a stack, you stop its EC2 instance, which gives the instance chance to bring the filesystem to a consistent state.

EBS

Regular EBS snapshots are not taken automatically. But, the EC2 instances are tagged according to the (default) scheme in the EBS Snapshot Scheduler.

If you wish to have backups then run an EBS Snapshot Scheduler stack. You only need one per AWS account, it will snapshot all tagged EC2 instances, regardless of which stack they are running in (also, free range EC2 instances not running in a stack).

You can run an EBS Snapshot Scheduler either by following their documentation, or by running a script in the refinery source tree:

python deployment/bin/snapshotscheduler.py

Once the EBS Snapshot Scheduler is running, instances that have a scheduler:ebs-snapshot tag will have their volumes backed up. You can manually add or remove this tag from instances to control whether their volumes are backed up.

As per the default policy of the EBS Snapshot Scheduler, backups are rotated away and deleted after 15 days.

RDS

We use the builtin RDS automatic backups. It is configured in the CloudFormation template.