Restoring from an Amazon EBS snapshot or an AMI - AWS Prescriptive Guidance

Restoring from an Amazon EBS snapshot or an AMI

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 RPO and 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.

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 can pre-warm your data from a snapshot into an EBS volume. For an additional charge, Amazon EBS supports fast snapshot restore, which reduces the need to pre-warm your data.

Your workload architecture impacts your restore procedure. For example, 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 an EBS volume from an Amazon EBS snapshot

You can restore a non-root volume attached to an existing EC2 instance by creating a volume from a 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.

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.

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. 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.

    2. 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.

    3. c. 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.

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.

You can use security groups to temporarily block all inbound connections for your new instance except for your own IP address for access and testing. This will prevent other servers and services from connecting to and utilizing your new instance before it is ready. 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 ready, stop the existing instance, and then start services and processes on the new instance.