Preferred EC2 instance backup procedures have been a common topic of discussion, specifically regarding the key differences between creating Amazon Machine Images (AMI) and using EBS snapshots. AMIs hold the data that is needed in order to launch a new EC2 instance and are preferred for keeping a golden image that can support the automated provisioning of the same baseline instance. Conversely, EBS snapshots are a backup of an EBS volume, from a specific point in time, that is stored in Amazon S3.
There are two main reasons why EBS snapshots make a much better instance backup solution than AMIs:
- Scalability – From our customers’, as well as our own, actual experience, it seems like parallel creation of large amounts of AMIs results in failures. Although I have been unable to find an official AWS statement to support these findings, a mass creation of AMIs does not appear to be allowed. Splitting the image creation, scheduling and consequently running the creations over a longer period of time may provide a solution, though certain limitations do exist.In an experiment, we found that generating 50 EBS snapshots in parallel to be successful, while the creation of the same amount of AMIs failed. Our platform generates hundreds of EBS snapshots a day with seldom failures such as those related to AMI creations.
- Consistency – The exact point in time an AMI creation begins is out of our control. Underneath an AMI, AWS creates snapshots. Since it is not possible to control when these snapshots are taken, their consistency is not a given. AMI creation can happen with or without a reboot of the instance:
- A reboot is not acceptable for production environments and is certainly not a viable option if images are expected to be created at a high frequency (i.e. every hour). These environments need to be available around the clock, leaving downtime out of the question.
- If an AMI is created without rebooting, consistency can become an issue due to the indeterminable point in time that the AMI was taken. As a result, a problem may arise when the instance is restored. Chances are that the restore operation will be fine, though if there are many transactions occurring within the instance, consistency will become an issue.
Backup of critical applications requires consistent snapshots, in which case EBS snapshots are more suitable. While running snapshots, the start times are known. Additionally, quiescing and data read-lock can be performed before a snapshot begins, immediately releasing the lock after inception. The lock release is a substantial benefit of snapshots due to the fact that databases cannot be locked for more than a few seconds. With image creation, because the exact backup time is not clear, either a prolonged wait time occurs before the system lock is released, or if the lock is not performed, the image may become inconsistent.
EC2 Instance Recovery
While recovery is an operation that is only performed from time to time, backups needs to run all of the time, and may be required to run frequently. However, the process of an EC2 instance restore from a snapshot differs depending on which operating system is used. By using EBS snapshots in a Linux instance, an image can be created easily, and can be used to launch a new instance. This extra manual step is generally not a problem for an automated backup solution such as CPM. In Windows, however, AWS does not allow AMIs to be created from a snapshot of the Root device (c:\ volume). This can be overcome by switching EBS volumes, an operation that can be done manually but becomes easier when using an automated backup solution.
N2WS Backup & Recovery is an enterprise-class backup solution for EC2 based on EBS & RDS snapshots. It supports consistent backup of applications on Linux servers as well as Windows servers. N2WS is sold on AWS Marketplace.
