Introduction
A report file was deleted, and your team needs to recover it from a tested backup. You will prepare synthetic report data, take an EBS snapshot, deliberately delete the exercise file and restore its earlier contents on a new volume. You will verify the application's recovered response before cleanup.
You should already know how to create, attach, format and mount an EBS data volume. This independent environment supplies its own image, network and key pair; it does not reuse resources from an earlier lab.
Certification Relevance
Snapshot backup and recovery support storage concepts in Task 3.6 of the AWS Certified Cloud Practitioner CLF-C02 Domain 3 objectives.
Launch the Recovery Server
In this step, you will launch the application instance and identify its Availability Zone.
Start in your workspace and load the supplied resource IDs:
cd /home/labex/project
source launch.env
Launch one instance named recovery-server. The image already contains a report application; your work will supply its data volume:
aws ec2 \
run-instances \
--image-id "$AMI_ID" \
--instance-type t3.micro \
--subnet-id "$SUBNET_ID" \
--security-group-ids "$SECURITY_GROUP_ID" \
--key-name report-key \
--count 1 \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=recovery-server}]'
Capture the instance ID from its name tag:
INSTANCE_ID=$(aws ec2 \
describe-instances \
--filters Name=tag:Name,Values=recovery-server \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Wait for the instance to run:
aws ec2 \
wait instance-running \
--instance-ids "$INSTANCE_ID"
An Availability Zone is an isolated location within a Region. An EBS volume attaches to an instance in the same Availability Zone. Retrieve the instance's zone rather than guessing it:
AVAILABILITY_ZONE=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].Placement.AvailabilityZone' \
--output text)
Inspect the state and zone:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,Zone:Placement.AvailabilityZone}'
Confirm running. Open AWS View, click Refresh resources, select recovery-server and click Check application. Confirm HTTP 200 before adding storage.
Prepare the Source Report
In this step, you will create an original data volume and write the synthetic report that you will back up.
Amazon EBS provides block storage for EC2. A volume is a disk-like resource, while a filesystem organizes files on that disk. Attaching a volume makes its block device available; it does not create a filesystem. The EBS volume guide describes volume attachment and persistence.
Create a small, empty general-purpose SSD volume. gp3 selects the volume type, --size 1 requests one GiB, and the zone variable places it alongside your instance. Capture its ID for later operations:
VOLUME_ID=$(aws ec2 \
create-volume \
--availability-zone "$AVAILABILITY_ZONE" \
--size 1 \
--volume-type gp3 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=source-report}]' \
--query 'VolumeId' \
--output text)
Wait until the new volume is available:
aws ec2 \
wait volume-available \
--volume-ids "$VOLUME_ID"
Attach it using the API device name /dev/sdf:
aws ec2 \
attach-volume \
--volume-id "$VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdf
Wait for attachment:
aws ec2 \
wait volume-in-use \
--volume-ids "$VOLUME_ID"
Inspect the volume and attachment:
aws ec2 \
describe-volumes \
--volume-ids "$VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Zone:AvailabilityZone,Size:Size,Type:VolumeType,Attachments:Attachments}'
Confirm in-use, size 1, type gp3 and an attachment to your instance. Refresh AWS View and inspect its volume row. The root volume is separate from the new data volume.
Retrieve the instance's current public address:
PUBLIC_IP=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
Connect using the supplied SSH configuration:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Inside the instance, inspect the newly attached device. Its Linux name in this lab is /dev/xvdf; device names can differ from the API attachment name. Other EC2 images may expose NVMe names, so identify a disk before operating on it. The official Linux volume preparation guide explains this distinction.
lsblk -f /dev/xvdf
Confirm the device has no filesystem type. Create an ext4 filesystem only on this newly created, empty data volume. Formatting a volume with existing data would erase it:
sudo mkfs.ext4 /dev/xvdf
A mount point is the directory through which you access a filesystem. Mount the new filesystem at the report application's prepared directory:
sudo mount /dev/xvdf /srv/reports
Confirm the source device, filesystem and mount point:
findmnt /srv/reports
Look for /dev/xvdf, ext4 and /srv/reports. Create a synthetic CSV report. sudo tee writes to the administrator-owned filesystem; the quoted here-document preserves the two lines:
sudo tee /srv/reports/report.csv <<'CSV'
period,total
Q1,320
CSV
Read the file back:
cat /srv/reports/report.csv
Return to the LabEx terminal:
exit
In AWS View, select recovery-server and click Read volume report. Confirm HTTP 200 and the CSV text period,total and Q1,320. This response demonstrates that the application can read the file from the mounted volume.
The mount in this lab is manual. A reboot does not automatically restore a manual mount; production setups typically configure a filesystem UUID in /etc/fstab after testing the entry.
Take a Consistent Snapshot
In this step, you will pause filesystem access and back up the source volume.
An EBS snapshot is a point-in-time backup of a volume. A backup must include the data you need, not just have a successful resource status. AWS recommends pausing writes or unmounting the volume for consistency, as described in the snapshot creation guide. This lab unmounts the data filesystem before taking its backup.
Connect to the instance:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Unmount the source filesystem to flush writes and stop filesystem access:
sudo umount /srv/reports
Return to the LabEx terminal:
exit
Create a snapshot of your source volume. Capture its ID and label it report-backup:
SNAPSHOT_ID=$(aws ec2 \
create-snapshot \
--volume-id "$VOLUME_ID" \
--description 'Report before accidental deletion' \
--tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=report-backup}]' \
--query 'SnapshotId' \
--output text)
Snapshot creation is asynchronous. Wait until it has completed:
aws ec2 \
wait snapshot-completed \
--snapshot-ids "$SNAPSHOT_ID"
Inspect its state and source volume:
aws ec2 \
describe-snapshots \
--snapshot-ids "$SNAPSHOT_ID" \
--query 'Snapshots[].{Snapshot:SnapshotId,State:State,SourceVolume:VolumeId}'
Confirm completed and the expected source volume. Refresh AWS View to inspect the snapshot. You will test its contents by restoring it after a deliberate file deletion.
Observe an Accidental File Deletion
In this step, you will remove the synthetic report from the source volume and observe the application's missing report.
Reconnect and remount the original volume:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo mount /dev/xvdf /srv/reports
Delete only the synthetic file you created for this exercise:
sudo rm /srv/reports/report.csv
Return to the LabEx terminal:
exit
In AWS View, select recovery-server and click Read volume report. The request should still return HTTP 200, but report is now null. The application is running; the file it needs is missing. This separates a storage-content problem from a stopped-server problem.
Your snapshot was created before this deletion. It can supply a new volume containing the earlier report without modifying the original volume.
Restore a New Volume from the Snapshot
In this step, you will restore the backup into a separate volume and switch the application to the recovered filesystem.
Restoration creates a new volume; it does not undo changes in the existing volume. Create the replacement in the instance's Availability Zone, using your completed snapshot. The official restoration guide describes this replacement workflow:
RESTORED_VOLUME_ID=$(aws ec2 \
create-volume \
--availability-zone "$AVAILABILITY_ZONE" \
--snapshot-id "$SNAPSHOT_ID" \
--volume-type gp3 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=recovered-report}]' \
--query 'VolumeId' \
--output text)
Wait until it is ready:
aws ec2 \
wait volume-available \
--volume-ids "$RESTORED_VOLUME_ID"
Attach it as a second data device:
aws ec2 \
attach-volume \
--volume-id "$RESTORED_VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdg
aws ec2 \
wait volume-in-use \
--volume-ids "$RESTORED_VOLUME_ID"
Inspect the replacement's snapshot relationship:
aws ec2 \
describe-volumes \
--volume-ids "$RESTORED_VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Snapshot:SnapshotId}'
Confirm in-use and the saved snapshot ID. Connect to switch the application mount:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Unmount the original filesystem:
sudo umount /srv/reports
Inspect the recovered device, exposed as /dev/xvdg in this lab:
sudo lsblk -f /dev/xvdg
It already contains an ext4 filesystem copied from the backup. Do not format this device: formatting would overwrite the restored data. Mount its existing filesystem at the application's report directory:
sudo mount /dev/xvdg /srv/reports
Confirm the active source:
findmnt /srv/reports
Look for /dev/xvdg. Read the recovered report:
cat /srv/reports/report.csv
Expect the original two lines, period,total and Q1,320. Return to the LabEx terminal:
exit
In AWS View, click Refresh resources, select recovery-server and click Read volume report. Confirm HTTP 200 and the original CSV text. A successful restore test proves that this backup contains usable application data.
Remove Recovery Resources
In this step, you will clean up both data volumes, the snapshot and the instance.
Connect and unmount the recovered filesystem:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo umount /srv/reports
exit
Detach the recovered volume:
aws ec2 \
detach-volume \
--volume-id "$RESTORED_VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdg
aws ec2 \
wait volume-available \
--volume-ids "$RESTORED_VOLUME_ID"
The source filesystem was unmounted during restoration. Detach its volume too:
aws ec2 \
detach-volume \
--volume-id "$VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdf
aws ec2 \
wait volume-available \
--volume-ids "$VOLUME_ID"
Delete the two detached exercise volumes:
aws ec2 \
delete-volume \
--volume-id "$RESTORED_VOLUME_ID"
aws ec2 \
delete-volume \
--volume-id "$VOLUME_ID"
Delete the exercise backup after its restore test:
aws ec2 \
delete-snapshot \
--snapshot-id "$SNAPSHOT_ID"
Terminate your server and wait for its final state:
aws ec2 \
terminate-instances \
--instance-ids "$INSTANCE_ID"
aws ec2 \
wait instance-terminated \
--instance-ids "$INSTANCE_ID"
Confirm the instance is terminated:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
List your named exercise volumes and backup:
aws ec2 \
describe-volumes \
--filters Name=tag:Name,Values=source-report,recovered-report \
--query 'Volumes[].VolumeId'
aws ec2 \
describe-snapshots \
--filters Name=tag:Name,Values=report-backup \
--query 'Snapshots[].SnapshotId'
Both lists should be []. Refresh AWS View and confirm the exercise volumes and snapshot are gone and the server is no longer a running target. Leave the prepared network and key pair in place.
Summary
You backed up a report volume with an EBS snapshot, observed the effect of deleting a file and restored a separate volume from the backup. You mounted the existing recovered filesystem without formatting it and verified the original application data. Finally, you removed both data volumes, the snapshot and the instance.
