AWS re/Start Lab · Storage

Working with Amazon EBS

Create an EBS volume, attach it to an EC2 instance, format it with ext3, persist the mount through /etc/fstab, take a snapshot to S3, and restore the snapshot into a new volume to recover deleted data.

Lab Summary

Provisioned a gp2 1 GiB volume in the same Availability Zone as the Lab instance, attached it as /dev/sdb, formatted with ext3 and mounted under /mnt/data-store. Persisted the mount via /etc/fstab, wrote a test file, snapshotted the volume, deleted the file, and proved recovery by creating a new volume from the snapshot and mounting it at /mnt/data-store2.

Volume lifecycle

Create → attach → format → mount → persist. Volumes are AZ-bound and exposed to Linux as block devices. On Nitro instances /dev/sdb appears as /dev/nvme1n1.

Snapshot lifecycle

Snapshot → delete data → restore. Snapshots live in S3, are incremental, and can be used to clone a volume in any AZ of the same Region.

Architecture & components

All resources sit in the same Region and the volume is co-located with the instance because EBS volumes are bound to a single Availability Zone.

Component Configuration Purpose
Lab EC2 instance Pre-provisioned, Amazon Linux, Nitro-based. AZ us-west-2a. Host where volumes are attached and mounted.
Root volume gp2, 8 GiB, attached as /dev/nvme0n1p1. Pre-existing OS disk — not modified.
My Volume gp2, 1 GiB, same AZ as Lab. Attached as /dev/sdb. Working volume created in this lab. Formatted with ext3.
My Snapshot Point-in-time copy of My Volume. 53 MiB stored. Backup. Persists in S3 independently of the source volume.
Restored Volume gp2, 1 GiB, created from My Snapshot. Attached as /dev/sdc. Recovery target. Contains the data that existed at snapshot time.

Walkthrough

Five technical tasks: provision the volume, attach it, mount it, snapshot it, and restore. The console clicks are summarized; the CLI work is documented in full.

01

Create and attach the EBS volume

  • From the EC2 console → Elastic Block Store · Volumes → Create volume. Configured gp2 · 1 GiB in the same AZ as the Lab instance (AZ-binding is mandatory for attach).
  • Tagged the volume Name=My Volume for identification next to the existing 8 GiB root volume.
  • From Actions · Attach volume, picked the Lab instance and device name /dev/sdb. State moved to In-use.
My Volume successfully attached to the Lab instance
EC2 console: My Volume (gp2, 1 GiB) attached to the Lab instance. The 8 GiB root volume is visible alongside.
AZ-binding: if the volume is created in a different AZ than the instance, attach is impossible. The fix is recreating the volume in the correct AZ — there is no cross-AZ attach.
02

Connect via EC2 Instance Connect and inspect the disk

  • Used EC2 Instance Connect from the console (no SSH key handling needed — the browser-based terminal is enough for this lab).
  • Ran df -h before doing anything: only the root volume /dev/nvme0n1p1 shows up. The new volume is attached at the EC2 layer but Linux has not been told what to do with it yet.
# Before formatting / mounting, the new volume is invisible to df
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        464M     0  464M   0% /dev
tmpfs           473M     0  473M   0% /dev/shm
/dev/nvme0n1p1  8.0G  1.7G  6.4G  21% /
Device naming on Nitro: the console asks for /dev/sdb, but inside the OS the kernel exposes it as /dev/nvme1n1. The sdX names still work as aliases, but df and findmnt will report nvmeXn1.
03

Format, mount, and persist the volume

  • Created an ext3 filesystem on the raw block device, then a mount point under /mnt/data-store and mounted it.
  • Added an entry to /etc/fstab so the mount survives reboots — without this, the volume would have to be remounted manually on every boot.
  • Wrote a small text file to prove the filesystem works, then read it back.
# 1. Format the raw block device
sudo mkfs -t ext3 /dev/sdb

# 2. Mount point + mount
sudo mkdir /mnt/data-store
sudo mount /dev/sdb /mnt/data-store

# 3. Persist across reboots
echo "/dev/sdb /mnt/data-store ext3 defaults,noatime 1 2" | sudo tee -a /etc/fstab

# 4. Verify
cat /etc/fstab
df -h
findmnt /mnt/data-store

# 5. Write & read a test file
sudo sh -c "echo some text has been written > /mnt/data-store/file.txt"
cat /mnt/data-store/file.txt
Terminal showing fstab entry, df -h with /dev/nvme1n1 mounted, findmnt, and file write/read
Terminal evidence: /etc/fstab entry, df -h showing /dev/nvme1n1 mounted on /mnt/data-store, findmnt confirming ext3, and the write/read cycle returning "some text has been written". Scroll the panel — the terminal output is dense on purpose.
noatime: the flag disables write-on-read for access timestamps. Reasonable default for general-purpose data volumes — fewer pointless writes, slightly less wear on the device.
04

Snapshot the volume to S3

  • From Volumes → selected My Volume → Actions · Create snapshot, tagged Name=My Snapshot.
  • Snapshot moves through Pending → Completed. Once Completed, the volume can be detached, deleted, or modified without affecting the snapshot — they are independent.
Snapshots listing showing My Snapshot, 53 MiB used, 1 GiB volume size
Snapshot listing: My Snapshot at 53 MiB stored for a 1 GiB source volume — only used blocks are persisted.
Incremental storage: the snapshot is 53 MiB even though the volume is 1 GiB. EBS only copies the blocks that were actually written (filesystem metadata + the test file). Subsequent snapshots of the same volume only store the delta.
05

Delete the file and restore it from the snapshot

  • Deleted file.txt on the original mount and confirmed it was gone with ls.
  • From Snapshots → Actions · Create volume from snapshot, same AZ, tagged Name=Restored Volume. Attached the new volume as /dev/sdc.
  • Created /mnt/data-store2, mounted the restored volume there, and the deleted file reappeared exactly as it was at snapshot time.
# Wipe the file on the original volume
sudo rm /mnt/data-store/file.txt
ls /mnt/data-store/file.txt
# → ls: cannot access /mnt/data-store/file.txt: No such file or directory

# Mount the restored volume (attached as /dev/sdc → /dev/nvme2n1 on Nitro)
sudo mkdir /mnt/data-store2
sudo mount /dev/sdc /mnt/data-store2

# The file is back — exactly as it existed at snapshot time
ls /mnt/data-store2/file.txt
# → /mnt/data-store2/file.txt
Terminal showing rm of file.txt, failed ls, then mount of /dev/sdc and successful ls
Recovery evidence: deletion on the original mount, the restored volume mounted at /mnt/data-store2, and the file recovered intact.
Why this matters: the restore happens at the block level. The new volume ships with the same filesystem and the same file metadata — no mkfs needed, just mount.

Command reference

Quick lookup for the storage commands used in this lab.

Command Purpose Notes
df -h List mounted filesystems with human-readable sizes. Does not show attached-but-unmounted volumes.
mkfs -t ext3 /dev/sdb Create an ext3 filesystem on a raw block device. Destructive — wipes whatever was on the device.
mount /dev/sdb /mnt/data-store Attach the filesystem to a directory in the tree. Non-persistent. Lost on reboot unless declared in /etc/fstab.
findmnt <path> Show source device, fs type, and mount options for a path. Better than parsing mount output.
/etc/fstab entry Declare a mount so it persists across reboots. Fields: device mountpoint fstype options dump pass.
cat / echo > /mnt/... Write and read a file to validate the filesystem. Use sudo sh -c "..." for the redirect — sudo echo > fails because the shell, not echo, owns the redirect.

Concepts & gotchas

What was actually learned

✓
EBS volumes are AZ-bound. They can only be attached to instances in the same Availability Zone.
✓
Attaching at the AWS layer is not the same as mounting. Linux still needs mkfs + mount before the volume is usable.
✓
Snapshots are point-in-time backups stored in S3, incremental, and independent from the source volume's lifecycle.
✓
A restored volume is a full clone of the snapshot — same filesystem, same data, no formatting required.
✓
/etc/fstab is the difference between "works now" and "works after reboot".

Technical conclusion

EBS gives you a block device. AWS handles durability and provisioning; the OS handles filesystem, mount, and persistence. The two layers don't overlap — losing track of which side is responsible for what is the most common source of confusion.

Snapshots are the cleanest backup primitive in this stack: incremental, region-durable, and restorable into any AZ. Combined with /etc/fstab persistence, this is the minimum-viable durable-storage pattern for any stateful workload on EC2.

sdb vs nvme1n1

The console says /dev/sdb. The OS on Nitro instances shows /dev/nvme1n1. Both work — the sdX names are symlinks/aliases — but monitoring tools and df will use the NVMe name.

AZ mismatch on attach

Creating the volume in the wrong AZ silently breaks the lab — the instance never appears in the attach dropdown. Always confirm the AZ of the target instance before clicking Create.

Forgetting /etc/fstab

A manual mount works until the next reboot. The fstab entry is what makes the configuration survive. The 1 2 fields at the end control dump and fsck ordering — not optional.

Snapshot size ≠ volume size

A 1 GiB volume produced a 53 MiB snapshot because EBS only stores used blocks. Useful for cost forecasting — billing is on snapshot storage, not nominal volume size.