How to Recover Data from a Broken EC2 Instance

By Ravindra Bagale, trainer · LinkedIn · Last updated: 18 October 2026

1. Root volume and data volumes

Why: Recovery is only possible because the data lives on a volume, separate from the server. Knowing which volume holds what tells you what you can save.

What: an EBS volume is a disk for an EC2 server. The root volume holds the operating system; Linux boots from it. Any extra disks are data volumes.

1. Size: Amazon Linux starts with an 8 GiB gp3 root volume by default; Windows Server starts with 30 GiB.
2. Device name: the root volume of Amazon Linux is /dev/xvda. Data volumes get names such as /dev/sdf.
3. Data volumes are added in Configure storage > Add new volume at launch, or attached later.

What EBS costs, and what happens to it on stop and terminate, is in The EBS bill: real numbers and Step 6: Storage.

2. Interview question: can you get the data back from a terminated server?

Why: Interviewers ask it to see whether you know that terminate deletes the root volume by default. The answer decides how you protect data from day one.

The honest answer: only if the disk still exists. By default the root volume has Delete on termination: Yes, so when the server is terminated, its root volume is deleted with it, and the data is gone.

The data survives a terminate in four cases:

1. You detached the root volume before terminating (this chapter's lab).

2. Delete on termination was set to No for that volume. At launch it is in Configure storage > Advanced. For a running server, use the AWS CLI:

   aws ec2 modify-instance-attribute --instance-id INSTANCE_ID --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"DeleteOnTermination":false}}]'
   

3. You have a snapshot of the volume.

4. You have an AMI of the server.

Data volumes that you attach after launch default to No, so they stay behind as Available (and keep costing money) after a terminate.

3. The lab: a server with a website and some files

What: one Amazon Linux 2023 t3.micro with the default 8 GiB root volume, a web page and three files, so you can see that they come back.

How:

sudo yum install httpd -y
echo "<h1>Hello from the old disk</h1>" | sudo tee /var/www/html/index.html
sudo service httpd start
sudo systemctl enable httpd
touch f1 f2 f3
ls

1. sudo service httpd start prints Redirecting to /bin/systemctl start httpd.service. That is not an error: on Amazon Linux 2023 the old service command hands the job to systemctl, and Apache starts.
2. sudo systemctl enable httpd makes Apache start at every boot, also when this disk boots on another server later.
3. The files are in /home/ec2-user. If you switched to root with sudo su -, files you create land in /root instead.
4. In the security group, add an inbound rule HTTP, port 80 from Anywhere-IPv4, then open http://PUBLIC_IP/ in the browser.

The full Apache set-up is in Host a website on EC2 with Apache, and the port 80 rule in Step 6: open port 80.

4. Volume states, and the Availability Zone rule

Why: A volume can attach only to a server in its own AZ. Forgetting this is why the server you want is missing from the attach list.

What: Elastic Block Store > Volumes lists every volume with its Volume state.

1. In-use: attached to an instance.
2. Available: not attached to anything; free to attach. It still costs money.
3. You also see Creating and Deleting for a short time.

The Availability Zone rule: a volume lives in one Availability Zone (AZ), such as ap-southeast-1c, and can only be attached to an instance in the same AZ. A volume in 1c doesn't even show up when you try to attach it to an instance in 1a.

5. How: recover data by swapping the root volume

Why: When a server won't boot, its disk is usually fine. Moving the disk to a healthy server brings the whole system back, not just a few files.

The idea: a server has exactly one root volume. Take the old server's root volume, and make it the root volume of a new server.

Part A: free the old disk.

1. Select the old server, Instance state > Stop, and wait for Stopped. A root volume can only be detached from a stopped instance.
2. Open its Networking tab and note the Availability Zone, for example ap-southeast-1c.
3. Open its Storage tab and click the root volume. In Volumes, give it a Name such as old-root (pencil in the Name column), so you can tell the volumes apart.
4. Select old-root, Actions > Detach volume, and confirm. The state changes from In-use to Available.
5. The old server can now be terminated; the detached volume stays.

Part B: a new server in the same AZ.

1. Launch instances, Amazon Linux 2023, the same key pair as the old server, so your .pem works on the old disk too.

2. Network settings > Edit > Subnet: pick the subnet in the old server's AZ. (Or set Availability Zone under the subnet list; "No preference" can land anywhere.)

3. Launch it, wait for Running, then Instance state > Stop, and wait for Stopped.

4. In its Storage tab, click its root volume, name it spare-root, and Actions > Detach volume.

Part C: attach the old disk as the root volume.

1. Select old-root, Actions > Attach volume.
2. Instance: pick the new, stopped server. It is only listed when it is in the same AZ.
3. Device name: /dev/xvda, listed under Reserved for root volume. Then Attach volume. The state becomes In-use.

Part D: start and check.

1. Instance state > Start. The new server gets a new public IP.

2. Connect, then:

   ls
   sudo service httpd status
   

3. f1 f2 f3 are there. httpd shows active (running) because it was enabled; if it shows inactive (dead), run sudo service httpd start.

4. Open http://NEW_PUBLIC_IP/: the old page is back.
5. Delete spare-root (Actions > Delete volume), or it keeps costing money.

6. The easier way: attach the old disk as a second disk

Why: to copy a few files off a broken disk, you don't need to boot from it. Attach it to any running server in the same AZ as a data volume and read it.

How:

1. Select old-root, Actions > Attach volume, pick a running server in the same AZ, device name /dev/sdf. No stop is needed.

2. On that server:

   lsblk
   sudo mkdir /mnt/old
   sudo mount -o nouuid /dev/nvme1n1p1 /mnt/old
   ls /mnt/old/home/ec2-user /mnt/old/var/www/html
   

3. On t3 servers the disk shows up as nvme1n1, not sdf; its first partition nvme1n1p1 holds the files.

4. Why -o nouuid: Amazon Linux 2023 uses the XFS filesystem. A disk made from the same AMI carries the same filesystem UUID as the server's own root disk, and XFS refuses to mount a second filesystem with the same UUID: mount fails with wrong fs type, bad option, bad superblock, and sudo dmesg shows Filesystem has duplicate UUID ... can't mount. nouuid tells XFS to skip that check.
5. Copy what you need, then sudo umount /mnt/old and Actions > Detach volume.
6. Detach it before you reboot that server. Both disks have the same UUID, and the server boots its root by UUID, so it could start from the wrong disk.

7. What an AMI is, and why you make one

Why: Setting up a server takes time. An AMI saves that setup once, so the next server starts ready, in seconds.

What: an AMI (Amazon Machine Image) is the template of a server: the OS, the installed software (Apache, Jenkins), the files and the settings, plus a snapshot and the size of each volume. AWS gives you AMIs (Amazon Linux, Ubuntu); you can also make your own.

What it is for:

1. Many identical servers: set up one, launch ten from its AMI.
2. Another Region: copy the AMI, launch it there.
3. Recovery: if a server dies or is deleted, launch it again from its AMI.

More examples are in What an AMI is and why we make one.

8. How: create an AMI and launch from My AMIs

1. Put something on the server to recognise: touch file1 file2 file3 file4 and mkdir dir1 dir2 dir3.
2. Select the instance, Actions > Image and templates > Create image, name it image-1, and Create image.
3. Reboot instance is ticked by default: EC2 reboots the server so the files are complete on disk when the snapshot is taken. Untick it only if you can't afford the reboot; the copy may then miss files that were still being written. The form is shown in Create an image (AMI) of your server.
4. Images > AMIs: wait until image-1 changes from Pending to Available.
5. Launch instances > Application and OS Images > My AMIs, choose image-1, and launch.
6. Connect and run ls: the files are there.

Two interview points:

1. Any instance type works. An AMI made from a t3.micro launches fine as a t3.small; the type is chosen at launch.
2. The AMI holds no key pair. You pick one at launch, and that key logs in. (The old public key is still inside authorized_keys on the disk, so the old key works too.)

9. AMI vs launch template

Why: The two are easy to confuse, and they solve different problems: an AMI is the disk contents; a launch template is the launch settings.

What: both help you launch servers, but they hold different things.

10. Copy an AMI to another Region

Why: To move a server to another Region, or keep a copy safe from a Region-wide problem, you need the AMI in that Region.

An AMI belongs to one Region. AMIs, select it, Actions > Copy AMI, choose the destination Region, then launch from the copy there. The full steps, and what has to be set up again, are in Move an EC2 server to another Region.

11. Snapshot vs AMI

Why: Both are backups, at different sizes: one disk versus a whole launchable server. Picking the right one saves cost and restore time.

What: a snapshot is a point-in-time backup of one EBS volume. An AMI is a launchable template of a whole server; behind it are snapshots, one per volume.

1. Creating an AMI creates a snapshot of each of the server's volumes automatically. Look in Elastic Block Store > Snapshots: the description says Created by CreateImage.
2. Snapshots are incremental: the first one stores all used blocks, the next ones only the blocks that changed. Each one still restores a complete disk. Worked numbers: Snapshots are incremental.

12. How: create a snapshot of a volume or of an instance

Why: A snapshot is cheap insurance before a risky change. Taking one is a single click, so there is no reason to skip it.

1. Elastic Block Store > Snapshots > Create snapshot.
2. Resource type:
   1. Volume: one snapshot of one volume. Pick the Volume ID: open the server's Storage tab first to see which volume is its root.
   2. Instance: one snapshot of every volume of an instance, all taken at the same moment, so they match. You can exclude the root volume or chosen data volumes.
3. Add a description and a Name tag such as ec2-snapshot, then Create snapshot. The status goes from Pending to Completed.

13. Interview question: can you launch an EC2 straight from a snapshot?

Why: It tests whether you know the chain: snapshot to volume or AMI, and only then a server.

No. A snapshot is a backup of one disk; it has no boot settings. There are two roads.

Road 1: snapshot to AMI to EC2.

1. Snapshots, select the snapshot of a root volume, Actions > Create image from snapshot.
2. Name it, for example image-snapshot. Keep Architecture the same as the original server (x86_64 for t3.micro) and the Root device name /dev/xvda; leave the rest as it is. Create image.
3. AMIs: wait for Available, then Launch instance from AMI.

Road 2: snapshot to volume, then attach.

1. Actions > Create volume from snapshot. Set the Availability Zone to the AZ of the server you will attach it to; the size can stay or grow.
2. Attach the new volume: as the root at /dev/xvda to a stopped server (section 5, Part C), or as a second disk at /dev/sdf (section 6).

A server from an AMI has exactly what was on the disk. If you made the snapshot before creating any files, the new server's ls is empty.

14. Task: snapshot, new volume, root swap

Why: This is the recovery path when the original volume is gone or must stay untouched: work from a snapshot instead.

The task: recover a server's files through a snapshot instead of the original disk.

1. Launch server-a, run touch f1 f2 f3.
2. Create a snapshot of its root volume (Resource type: Volume).
3. Create volume from snapshot in the AZ where the new server will run, for example ap-southeast-1c.
4. Launch server-b in that AZ with the same key pair, wait for Running, then Stop it.

5. Detach server-b's own root volume.

6. Attach the volume made from the snapshot to server-b at /dev/xvda.

7. Start server-b, connect, ls: f1 f2 f3 are there.
8. Clean up (section 16).

15. Deregister vs Disable an AMI

1. Disable AMI (Actions > Disable AMI): the AMI can't launch new servers and moves out of the normal list (filter Disabled images to see it). If it was public, it becomes private. Re-enable AMI brings it back. Its snapshots stay, and still cost money.
2. Deregister AMI (Actions > Deregister AMI): the AMI is removed for good. Its snapshots are not deleted unless you tick Delete associated snapshots; otherwise delete them yourself in Snapshots.
3. Servers already launched from the AMI keep running in both cases.

The deregister dialog is shown in Clean up: deregister the AMI and delete its snapshots.

16. Clean up: what keeps costing money

Why: Volumes, snapshots and AMIs keep costing money after the servers are gone. Checking each list is how you avoid a surprise bill.

After the lab, check each list in the console:

1. Instances: terminate the test servers. A stopped server's volumes are still billed.
2. Volumes: delete every Available volume you don't need (spare-root, volumes made from snapshots).
3. AMIs: deregister the test AMIs, with Delete associated snapshots ticked.
4. Snapshots: delete the ones you made by hand.
5. Elastic IPs: release any you allocated.

17. When something looks wrong

1. The new server isn't in the Attach volume list: it is in a different AZ than the volume. Launch it in the volume's AZ, or make a snapshot and create a volume in the right AZ.
2. Detaching a root volume fails or hangs: the server is still running. Stop it first.
3. Attaching at /dev/xvda fails because the name is in use: the new server's own root volume is still attached. Detach it first.
4. SSH fails after the swap: use the key pair the old server was launched with, the new public IP, and check port 22 in the security group.
5. The website doesn't open after the swap: sudo service httpd status. If it is inactive, start it, and sudo systemctl enable httpd for next time. Check port 80 in the security group.
6. mount fails with wrong fs type on the second disk: add -o nouuid (section 6); sudo dmesg | tail shows the duplicate UUID.
7. The launch from your AMI shows no files: the AMI or snapshot was made before the files were created, or the files are in /root because you worked as root.

18. The whole class on one page

1. The root volume holds the OS (/dev/xvda, 8 GiB gp3 on Amazon Linux); data volumes hold extra data (/dev/sdf).
2. Root volumes default to Delete on termination: Yes. Data survives a terminate only if you detached first, set No, or have a snapshot or AMI.
3. In-use means attached; Available means free (and still billed). A volume attaches only within its own AZ.
4. Recovery by swap: stop the old server, detach its root; launch a new server in the same AZ, stop it, detach its root; attach the old volume at /dev/xvda; start.
5. To just read the old files, attach as a second disk and sudo mount -o nouuid /dev/nvme1n1p1 /mnt/old; detach before a reboot.
6. An AMI is a server template; Create image reboots by default; launch from My AMIs with any instance type and any key pair.
7. AMI = what is on the disk; launch template = how to launch (type, key pair, subnet, security groups, user data).
8. A snapshot backs up one volume (incremental); an AMI points to one snapshot per volume.
9. Create snapshot: Volume for one disk, Instance for all disks at the same moment.
10. No launch from a snapshot: snapshot to image to EC2, or snapshot to volume to attach.
11. Disable hides an AMI and can be undone; Deregister removes it; neither deletes snapshots unless you ask.
12. Clean up instances, Available volumes, AMIs, snapshots and Elastic IPs.

19. Hands-on lab: read files off a stopped server's disk

Why this lab. When a server breaks, the files are usually still on its disk. This lab simulates that: it puts files on server A, stops it, attaches its root disk to server B, and reads the files there.

1. Put a file on server A
   • Command: echo "important data" > ~/keep.txt
   • You should see: Nothing.
   • Check: cat ~/keep.txt → important data
   • Why: A file you recognise proves later that you recovered the right disk.
2. Stop server A and detach its root volume
   • Do: Stop server A. In its Storage tab, open the root volume, then Actions → Detach volume. Name it old-root.
   • Check: Volumes shows old-root as Available.
   • Why: A root volume can be detached only from a stopped server. Stopping, unlike terminating, keeps the volume.
3. Attach it to server B
   • Do: Select old-root → Actions → Attach volume → pick server B (running, same AZ) → device /dev/sdf → Attach.
   • Check: The volume state becomes In-use.
   • Why: A volume attaches only within its AZ. If server B isn't in the list, it is in another AZ.
4. Find the new disk on server B
   • Command: lsblk
   • You should see: nvme0n1 (server B's own disk) and a new nvme1n1 with a partition nvme1n1p1.
   • Check: nvme1n1 has no mount point yet.
   • Why: On t3 servers /dev/sdf shows up as nvme1n1. The files are in its first partition.
5. Mount it
   • Command: sudo mkdir /mnt/old && sudo mount -o nouuid /dev/nvme1n1p1 /mnt/old
   • You should see: Nothing.
   • Check: df -h /mnt/old shows the old disk mounted there.
   • Why: Both disks come from the same AMI and share an XFS UUID. Without -o nouuid, the mount fails with wrong fs type, bad option, bad superblock.
6. Read the file
   • Command: cat /mnt/old/home/ec2-user/keep.txt
   • You should see: important data
   • Check: Copy it out: cp /mnt/old/home/ec2-user/keep.txt ~/.
   • Why: The old server's whole filesystem sits under /mnt/old, so its home is /mnt/old/home/ec2-user.
7. Unmount and detach
   • Command: cd ~ && sudo umount /mnt/old
   • You should see: Nothing.
   • Check: Then Actions → Detach volume on old-root; its state returns to Available.
   • Why: Detach before you reboot server B: with two disks sharing a UUID it could boot from the wrong one.
8. Clean up
   • Do: Terminate both servers and delete old-root in Volumes.
   • Check: Volumes shows no available volumes left.
   • Why: A detached volume keeps costing money every month, even with no server.

20. Try at home

Recap

Quick revision cards

Revise this lesson in two minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens its lesson.

More cards: Ravi Sir's Cards.