Amazon EC2 EBS backup: AMI vs Snapshot

Question

I am trying to create a backup mechanism for our server, so that if my system crashes, I should be able to create the whole system by running a single script

After going through Amazon documentation, this is my understanding of creating a backup and restoring

Backup

1. Create a AMI Image (this can be updated monthly)
2. Create a snapshot (This can be done using a daily script creating a snapshot)

Restore (A script to)

1. Create an EBS instance using AMI
2. Attach the EBS volume to Instance created

Now my Questions is

1. Is it the best way to take a backup and restore?
2. Do we actually need to backup 2 things, AMI and EBS volume (using snapshot), Can we just keep snapshots?
3. I understand this cannot work for a local instance store instance, as there is no snapshot functionality. So how can I create a backup and restore process for local instance store instances?

Solution 1

As I could not find any better alternative, I am sticking with the initial approach.

For EBS

Backup:

• Create a AMI Image (this can be updated monthly).
• Create a snapshot (This can be done using a daily script creating a snapshot).

Restore (A script to)

• Create an EBS instance using AMI.
• Attach the EBS volume to Instance created.

For instance store, I am only keeping the application (no database), so no need to keep a backup of that.

Solution 2

EBS Snapshots are an excellent way to create backups.

You can perform frequent Snapshots of your EBS Volumes via scripts. Weekly, Daily, Hourly, or as frequently as your Credit Card will allow. The only limit is around how many simultaneous snapshots you can be doing - when you hit that, the EBS API will start giving back errors until a few of the in-flight operations complete.

Snapshots can also be copied from Region to Region in order to provide backup against a catastrophic event.

When you snapshot an EBS volume, that snapshot is of the entire volume. Even if it was created from an AMI, your snapshot contains everything you need to create a new instance of the volume. You can pretty easily try this yourself.

Solution 3

I would suggest to use Auto Scaling in addition to EBS snapshots. If Instance is dying because of Hardware failure or it's scheduled for retirement by Amazon, Auto Scaling will start new Instance automatically.

But in this case, you have to setup NAS for your dynamic data. Depending on Server Load, the number of running Instances will be different and all your scaling servers must mount NAS storage which is shared across them.

Your Database should be on separate server or servers as well. Or you might want to use Amazon RDS as it has great auto-backup / Point-In-Time-Restore features, but you have to pay extra for that.

Solution 4

If your instances are Linux based, there is no need to create an AMI if you're taking snapshots. You can create the AMI on the fly, from the snapshots, when you need to recover. If you got that process automated, it's pretty easy to do.

• In Windows there is a limitation not allowing to launch an EC2 instance from a snapshot, so AMIs must be used. There are ways to workaround that limitation: You can check out the this post I wrote in our company's blog:

http://www.n2ws.com/blog/3-ways-ec2-windows-backup-and-recovery.html

Solution 5

1) Yes.Snapshot is best way to backup and restore EBS volumes.

2) Depends, if you have the root volume as EBS backed AMI, then you can snapshot them as well and improves the manageability

3) Rsync and AMI is the option available for instance store

View more solutions

Comments

[Devplex]

A few things I learned while trying to recover: Make a note of the Kernel ID from the original instance. You'll probably need to start your future AMI with the same kernel or it may not boot. Other metadata that may be useful to have available are any User-data, Security Groups, secondary IP's, instance-type and architecture. You could store some of that data in the Snapshot's description or tags.

[Martin Konecny]

@MartijnHeemels The only problem is making note of the Kernel ID is that they are not the same across regions - so if you are copying a snapshot to a different region, it's more complicated :/.

[Scott Willeke]

Why is this specific to linux? Can't the same process be used for windows?

[Kevin Wheeler]

@ScottWilleke Apparently it doesn't apply to all Linux flavors. "Some Linux distributions, such as Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES), use the EC2 billingProduct code associated with an AMI to verify subscription status for package updates. Creating an AMI from an EBS snapshot does not maintain this billing code, and subsequent instances launched from such an AMI will not be able to connect to package update infrastructure. Similarly, although you can create a Windows AMI from a snapshot, you can't successfully launch an instance from the AMI."

[Suncatcher]

Backup to AMI image can be automated as well in an arbitrary manner, even minutely.