I have been browsing my brains out to find a simple backup strategy for our single windows 2008 server running SharePoint Services. This is an EBS-backed image of one server with one data volume. I don’t need anything exotic. I only need a “daily” backup (losing a day’s worth of data is not catastrophic).

We have created and saved an EBS backed AMI image (Windows 2008) we are comfortable using. We started off making backups by simply creating a new EBS AMI image. This is really simple, but the running server is put offline during the first 10 – 15 minutes of creating the image – not ideal.

The standard way of creating backups would seem to be creating snapshots of volumes attached to a running instance. Again it’s pretty simple and the server remains usable during the snapshot generation. The apparent Catch-22 is that you can’t simply launch a new instance directly from a snapshot.

I know how to bundle a running instance to S3 storage and then register the AMI from the S3 bucket. This does allow me to capture a backup of a running instance and, if the running instance is lost, register the AMI from the S3 bucket and launch the new AMI to recover the instance, but this seems really convoluted and it seems ridiculous to have to juggle back and forth between the AWS Console and the S3 Organizer plug-in for Firefox to get this accomplished. (Please don't mention the command line approach, this is an 010 level course).

From playing around with EBS-backed images, the following approach appears to work for me (all done within the AWS Console):

1.For your backups, simply snapshot the system volume (/dev/sda1) as needed.
2.If you lose your running instance, do the following:
a.Create a new volume from your last snapshot backup
b.Launch another instance of your starting AMI (must be EBS-backed)
c.Stop this instance.
d.Detach the existing system volume from the new stopped instance and discard.
e.Attach the newly created volume as system volume (/dev/sda1) to the stopped instance.
f.Re-start the new instance.
I have tested this out a couple of times and it seems to work for me.

2 Answers
2

Your approach sounds very good - but I can think of a possible way to improve it.

To reduce the impact of data loss since the last backup, and EBS volume failure (unlikely, but still possible) you could store your data on a separate EBS volume than your system files, and back up the data volume more frequently than the system volume.

With your current strategy, you'll lose any data that was created between the time of the last backup and the time your instance failed. With the new approach, the data volume will be getting written to right up until the instance failure, so you can just reattach it to your new instance once it's up and running.