Skip to content

Mount EBS Volume with pre-existing data on EC2 without data loss

0

What is best practice when it comes to detecting when an already available AMI has been deprecated and the resource name needs an update to match the new version? Every 3 months a new EC2 instance is created because a new Amazon Linux 2023 AMI is released. This causes the EBS volume attached to the old instance to be deleted, and therefore all the data is lost.

A solution I found is to create a snapshot of the old volume and attach it to the new EC2 instance - the EC2 instance has two volumes attached - but only one is mounted(the one containing the OS). The problem with this is if I try to mount the second volume, according to the AWS docs one of the commands should not be used if the volume already has data on it.

Are there better solutions out there to tackle this? Or if this is the way to go, does anyone know how to mount the second volume without any data loss?

Working with CDKTF(CDK for Terraform) as IaC tool, so any tips on how to handle this in terraform would be much appreciated as well.

Thanks in advance!

1 Answer
0

To address your concern about data loss when updating EC2 instances due to new Amazon Linux 2023 AMI releases, there are several best practices and solutions you can consider:

  1. Separate Data Storage: Instead of relying solely on the root EBS volume, it's best to store your application data on a separate EBS volume. This way, when you need to update the EC2 instance, you can detach the data volume from the old instance and attach it to the new one without data loss.

  2. Use EBS Snapshots: Creating regular snapshots of your EBS volumes is a good practice. Before updating your EC2 instance, take a snapshot of the data volume. Then, when launching the new instance, you can create a new EBS volume from this snapshot and attach it to the new instance.

  3. Mounting the Volume: When mounting a volume with existing data, you're correct to be cautious. The key is to mount the volume without reformatting it. Here's a safe approach:

a. Attach the volume to your new EC2 instance. b. Use the 'lsblk' command to identify the new volume. c. Check if the volume has a file system using 'file -s /dev/xvdf' (replace xvdf with your volume name). d. If it has a file system, you can directly mount it without formatting: sudo mount /dev/xvdf /mnt/data

This approach allows you to mount the volume without losing any existing data.

  1. Automation: To handle AMI deprecation and updates automatically, you can use AWS Systems Manager Parameter Store to store the latest AMI ID. Update this parameter when a new AMI is released, and reference it in your infrastructure code.

  2. Infrastructure as Code: With CDKTF, you can create a separate EBS volume resource that persists across instance replacements. Use data sources to fetch the latest AMI ID, and update your EC2 instance resource to use this AMI. Attach the persistent EBS volume to the new instance in your code.

  3. Consider using Amazon EFS: If your use case allows, Amazon Elastic File System (EFS) can provide a persistent, scalable file storage that remains available even when EC2 instances are terminated or replaced.

By implementing these practices, you can ensure data persistence and smoother transitions when updating your EC2 instances due to AMI changes.
Sources
Make an Amazon EBS volume available for use - Amazon EBS
Attach an Amazon EBS volume to an Amazon EC2 instance - Amazon EBS
Replace an Amazon EBS volume using a snapshot - Amazon EBS

answered 2 years ago

EXPERT

reviewed 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.