Ravindra BagaleCourses & study guides

Chapter 14: EC2 Operations — Elastic IP, AMI, Snapshots and Vertical Scaling

14.3 EBS snapshots in practice

In short: A snapshot is a point-in-time, incremental backup of an EBS volume: the first copies all used blocks, later ones only changed blocks.

Quick recap

  • A snapshot is a point-in-time, incremental backup of an EBS volume: the first copies all used blocks, later ones only changed blocks.
  • Snapshots are stored in Amazon S3, managed by AWS — you don't see them in your S3 buckets.
  • Snapshots are regional: a volume created from a snapshot can go into any AZ of the region; copy the snapshot to use it in another region.

Create a snapshot of a volume

EC2 → Elastic Block Store → Volumes → select the volume (check the Attached resources column) → Actions → Create snapshot → description web-1-root-before-upgrade → tag Name → Create snapshot. Watch it under Snapshots until Completed. (Or from the instance's Storage tab → click the volume ID.)

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "web-1-root-before-upgrade"

Consistency

A snapshot captures what is on disk at that moment. For a data volume, stop the application or database writes (or at least sync) first. For a root volume, the cleanest snapshot is taken with the instance stopped. A snapshot of a running root volume usually works, but may be "crash-consistent" only.

Create a volume from a snapshot and mount it (file restore)

Scenario: a student accidentally deleted /var/www/mysite/index.html. We restore just that file from last night's snapshot without touching the running server.

Step 1 — Create volume: Snapshots → select the snapshot → Actions → Create volume from snapshot → type gp3 → size (same or larger) → Availability Zone = same as the instance you will attach to → Create volume.

Step 2 — Attach: Volumes → select the new volume → Actions → Attach volume → instance → device /dev/sdg → Attach.

Step 3 — Mount read-only and copy the file (do not run mkfs — it already has data!):

lsblk                                   # new disk, e.g. nvme1n1 with partition nvme1n1p1 (root snapshot)
sudo mkdir -p /restore
# XFS copy of a disk from the SAME instance has a duplicate UUID -> use nouuid
sudo mount -o ro,nouuid /dev/nvme1n1p1 /restore      # XFS (Amazon Linux / CentOS)
# sudo mount -o ro /dev/nvme1n1p1 /restore           # ext4 (Ubuntu)
ls /restore/var/www/mysite/
sudo cp -a /restore/var/www/mysite/index.html /var/www/mysite/
sudo umount /restore

Step 4 — Clean up: detach the temporary volume and delete it.

Full restore of a broken root volume

To roll back a whole server: stop the instance → create a volume from the good snapshot in the same AZ → detach the broken root volume → attach the restored volume with the same root device name shown in the instance's Storage tab (e.g. /dev/xvda) → start. Newer consoles also offer Replace root volume, which does this for you. Alternatively, create an AMI from the snapshot and launch a new instance.

Copy a snapshot to another region

Select the snapshot → Actions → Copy snapshot → destination region → (optional) encrypt → Copy snapshot.

aws ec2 copy-snapshot --source-region ap-south-1 --source-snapshot-id snap-0123456789abcdef0 \
  --region ap-south-2 --description "DR copy of web-1 root"

Create an AMI from a snapshot

For a snapshot of a root volume: select it → Actions → Create image from snapshot → name → architecture (must match the original, e.g. x86_64) → root device name (e.g. /dev/xvda) → virtualization hvm → boot mode (as the original) → Create image. You can then launch instances from it. (Creating the AMI from the instance, as in 14.2, is easier because AWS fills these details automatically.)

Automate snapshots with Amazon Data Lifecycle Manager

Manual snapshots are forgotten; automated ones are not. General steps (UI may vary):

  1. Tag the volumes (or instances) to protect, e.g. Backup = daily.
  2. EC2 → Elastic Block Store → Lifecycle Manager → Create lifecycle policy.
  3. Policy type EBS snapshot policy (or EBS-backed AMI policy to create AMIs) → target resource type Volume (or Instance) → target tag Backup = daily.
  4. IAM role: Default role → policy status Enabled.
  5. Schedule: e.g. every 24 hours starting at 03:00 UTC (08:30 IST) → retention type Count → keep 7 → optionally copy tags, enable cross-region copy.
  6. Create policy. Next day, check Snapshots for automatic snapshots tagged by DLM.

(AWS Backup is the broader, multi-service alternative used in many companies.)

Delete old snapshots

Snapshots → sort by Started → select old/unneeded snapshots → Actions → Delete snapshot. You cannot delete a snapshot that is used by a registered AMI — deregister the AMI first. Because snapshots are incremental, AWS keeps any blocks still needed by newer snapshots, so deleting an old one never breaks the newer ones.