Restoring an Amazon EBS volume or an EC2 instance

If you need to restore only a single volume attached to an EC2 instance, you can restore that volume separately, detach the existing volume, and attach the restored volume to your EC2 instance. If you need to restore an entire EC2 instance, including all of its associated volumes, you must use an Amazon Machine Image (AMI) backup of your instance.

To reduce the recovery time and impact to dependent applications and processes, your restore process must consider the resource that it is replacing. For best results, regularly test your restore process in lower environments (for example, non-production) to verify that your process meets your recovery point objective (RPO) and recovery time objective (RTO) and that the restore process works as expected. Consider how the restore process will impact applications and services that depend on the instance you are restoring, and then coordinate the restore as necessary. Try to automate and test the restore process as much as possible to reduce the risk of your restore process failing or being implemented inconsistently.

If you use Elastic Load Balancing, with multiple instances servicing traffic, you can take a failed or impaired instance out of service. Then you can restore a new instance to replace it while the other instances continue to service traffic without disruption to users.

The following restore processes described are for instances that are not using Elastic Load Balancing:

• Restoring individual files and directories from EBS snapshots

• Restoring an EBS volume from an Amazon EBS snapshot

• Creating or restoring an EC2 instance from an EBS snapshot

• Restoring a running instance from an AMI

Restoring files and directories from EBS snapshots

EBS snapshots provide a point-in-time exact replica of the original volume that was used to create the snapshot. To restore individual files or directories, you must do the following:

1. First, restore the volume from the EBS snapshot that contains the files or directories.

2. Attach the volume to the EC2 instance to which you want to restore the files.

3. Copy the files from the restored volume to your EC2 instance volume.

4. Detach and delete the restored volume.

Restoring an EBS volume from an Amazon EBS snapshot

You can restore a volume attached to an existing EC2 instance by creating a volume from its snapshot and attaching it to your instance. You can use the console, the AWS CLI, or the API operations to create a volume from an existing snapshot. You can then mount the volume to the instance by using the operating system.

Note that data from an Amazon EBS snapshot is asynchronously loaded into an EBS volume. If an application accesses the volume where the data is not loaded, there is higher latency than normal while the data is loaded from Amazon S3. To avoid this impact for latency-sensitive applications, you have two options:

• You can initialize the EBS volume.

• For an additional charge, Amazon EBS supports fast snapshot restore, which eliminates the need initialize your volume.

If you are replacing a volume that must use the same mount point, unmount that volume so that you can mount the new volume in its place. To unmount the volume, first stop any processes that are using the volume. If you are replacing the root volume, you must stop the instance first before you can detach the root volume.

For example, follow these steps to restore a volume to an earlier point-in-time backup by using the console:

1. On the Amazon EC2 console, on the Elastic Block Store menu, choose Snapshots.

2. Search for the snapshot that you want to restore, and select it.

3. Choose Actions, and then choose Create Volume.

4. Create the new volume in the same Availability Zone as your EC2 instance.

5. On the Amazon EC2 console, select the instance.

6. In the instance details, make note of the device name that you want to replace in the Root device entry or Block Devices entries.

7. Attach the volume. The process differs for root volumes and non-root volumes.

   For root volumes:

   1. Stop the EC2 instance.

   2. On the EC2 Elastic Block Store Volumes menu, select the root volume that you want to replace.

   3. Choose Actions, and then choose Detach Volume.

   4. On the EC2 Elastic Block Store Volumes menu, select the new volume.

   5. Choose Actions, and then choose Attach Volume.

   6. Select the instance that you want to attach the volume to, and use the same device name that you noted earlier.

   For non-root volumes:

   1. On the EC2 Elastic Block Store Volumes menu, select the non-root volume that you want to replace.

   2. Choose Actions, and then choose Detach Volume.

   3. Attach the new volume by choosing it on the EC2 Elastic Block Store Volumes menu and then choosing Actions, Attach Volume. Select the instance that you want to attach it to, and then select an available device name.

   4. Using the operating system for the instance, unmount the existing volume, and then mount the new volume in its place.

      In Linux, you can use the umount command. In Windows, you can use a logical volume manager (LVM) such as the Disk Management system utility.

   5. Detach any prior volumes that you may be replacing by choosing it on the EC2 Elastic Block Store Volumes menu and then choosing Actions, Detach Volume.

You can also use the AWS CLI in combination with operating system commands to automate these steps.

Creating or restoring an EC2 instance from an EBS snapshot

To create a backup that will be used to restore an entire EC2 instance, we recommend creating an Amazon Machine Image (AMI). AMIs capture machine information such as virtualization type. They also create snapshots for each volume that is attached to the EC2 instance, including their device mappings, so that they can be restored in the same configuration.

However, if you must use an EBS snapshot to restore an instance, first create an AMI from an EBS snapshot that will become the root volume for your new EC2 instance:

1. On the Amazon EC2 console, on the Elastic Block Store menu, choose Snapshots.

2. Search for the snapshot that will be used to create the root volume for your new EC2 instance, and select it.

3. Choose Actions, and then choose Create Image from Snapshot.

4. Enter a name for your image (for example, YYYYMMDD-restore-for-i-012345678998765de), and choose the appropriate options for your new image.

After the image is created and available, you can launch a new EC2 instance that will use the EBS snapshot for the root volume.

Restoring a running instance from an AMI

You can bring up a new instance from your AMI backup to replace an existing, running instance. One approach is to stop the existing instance, keep it offline while you launch a new instance from your AMI, and perform any necessary updates. This approach reduces the risk of conflicts from both instances running simultaneously. It is an acceptable approach if the services that your instance provides are down or you are performing the restore during a maintenance window. After you test your new instance, you can reassign any Elastic IP addresses that were allocated to the old instance. Then you can update any Domain Name Service (DNS) records to point to the new instance.

However, if during a restore you must minimize the downtime of your in-service instance, consider launching and testing a new instance from your AMI backup. Then replace the existing instance with the new instance.

While both instances are running, you must prevent the new instance from causing any platform-level or application-level collisions. For example, you might run into problems with domain-joined Windows instances that are running with the same SIDs and computer name. You might encounter similar issues with network applications and services that require unique identifiers.

To prevent other servers and services from connecting to your new instance before it's ready, use security groups to temporarily block all inbound connections for your new instance except for your own IP address for access and testing. You can also block outbound connections temporarily for the new instance to prevent services and applications from initiating any connections or updates to other resources. When the new instance is ready, stop the existing instance, start services and processes on the new instance, and then unblock any inbound or outbound network connections that you implemented.