소개
보고서 파일이 삭제되어 팀에서 테스트한 백업으로 복구해야 합니다. 가상 보고서 데이터를 준비하고 EBS 스냅샷을 만든 뒤 연습 파일을 의도적으로 삭제하여 이전 내용을 새 볼륨에 복원합니다. 리소스를 정리하기 전에 애플리케이션의 복구된 응답을 확인합니다.
EBS 데이터 볼륨의 생성, 연결, 포맷 및 마운트 방법을 이미 알고 있어야 합니다. 이 독립적인 환경은 자체 이미지, 네트워크 및 키 페어를 제공하며 이전 실습의 리소스를 재사용하지 않습니다.
자격증과의 관련성
스냅샷을 통한 백업과 복구는 AWS Certified Cloud Practitioner CLF-C02 도메인 3 목표의 작업 3.6에 포함된 스토리지 개념을 익히는 데 도움이 됩니다.
복구 서버 시작하기
이 단계에서는 애플리케이션 인스턴스를 시작하고 가용 영역을 확인합니다.
작업 디렉터리에서 제공된 리소스 ID를 불러옵니다.
cd /home/labex/project
source launch.env
recovery-server라는 이름의 인스턴스 하나를 시작합니다. 이미지에는 보고서 애플리케이션이 이미 포함되어 있으며, 여기서는 데이터 볼륨을 제공합니다.
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}]'
이름 태그로 인스턴스 ID를 가져옵니다.
INSTANCE_ID=$(aws ec2 \
describe-instances \
--filters Name=tag:Name,Values=recovery-server \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
인스턴스가 실행될 때까지 기다립니다.
aws ec2 \
wait instance-running \
--instance-ids "$INSTANCE_ID"
가용 영역은 리전 내의 격리된 위치입니다. EBS 볼륨은 같은 가용 영역에 있는 인스턴스에 연결합니다. 영역을 추측하지 말고 인스턴스의 영역을 조회합니다.
AVAILABILITY_ZONE=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].Placement.AvailabilityZone' \
--output text)
상태와 영역을 확인합니다.
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,Zone:Placement.AvailabilityZone}'
running을 확인합니다. AWS View를 열고 Refresh resources를 클릭한 다음 recovery-server를 선택하고 Check application을 클릭합니다. 스토리지를 추가하기 전에 HTTP 200을 확인합니다.
원본 보고서 준비하기
이 단계에서는 원본 데이터 볼륨을 생성하고 백업할 가상 보고서를 작성합니다.
Amazon EBS는 EC2용 블록 스토리지를 제공합니다. 볼륨은 디스크와 같은 리소스이며, 파일 시스템은 해당 디스크의 파일을 구성합니다. 볼륨을 연결하면 블록 장치를 사용할 수 있지만 파일 시스템이 생성되는 것은 아닙니다. EBS 볼륨 안내서에서는 볼륨 연결과 데이터 지속성을 설명합니다.
작고 비어 있는 범용 SSD 볼륨을 생성합니다. gp3는 볼륨 유형을 선택하고, --size 1은 1 GiB를 요청하며, 영역 변수는 인스턴스와 같은 영역에 배치합니다. 이후 작업을 위해 ID를 저장합니다.
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)
새 볼륨을 사용할 수 있을 때까지 기다립니다.
aws ec2 \
wait volume-available \
--volume-ids "$VOLUME_ID"
API 장치 이름 /dev/sdf를 사용하여 연결합니다.
aws ec2 \
attach-volume \
--volume-id "$VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdf
연결이 완료될 때까지 기다립니다.
aws ec2 \
wait volume-in-use \
--volume-ids "$VOLUME_ID"
볼륨과 연결 정보를 확인합니다.
aws ec2 \
describe-volumes \
--volume-ids "$VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Zone:AvailabilityZone,Size:Size,Type:VolumeType,Attachments:Attachments}'
in-use, 크기 1, 유형 gp3, 그리고 자신의 인스턴스에 연결되었는지 확인합니다. AWS View를 새로 고침하여 볼륨 행을 확인합니다. 루트 볼륨은 새 데이터 볼륨과 별개입니다.
인스턴스의 현재 퍼블릭 주소를 가져옵니다.
PUBLIC_IP=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
제공된 SSH 설정으로 연결합니다.
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
인스턴스 내부에서 새로 연결된 장치를 확인합니다. 이 실습의 Linux 장치 이름은 /dev/xvdf이며, 장치 이름은 API 연결 이름과 다를 수 있습니다. 다른 EC2 이미지에서는 NVMe 이름이 표시될 수 있으므로 작업 전에 디스크를 식별해야 합니다. 공식 Linux 볼륨 준비 안내서에서 이 차이를 설명합니다.
lsblk -f /dev/xvdf
장치에 파일 시스템 유형이 없는지 확인합니다. 새로 생성한 빈 데이터 볼륨에만 ext4 파일 시스템을 생성합니다. 기존 데이터가 있는 볼륨을 포맷하면 데이터가 삭제됩니다.
sudo mkfs.ext4 /dev/xvdf
마운트 지점은 파일 시스템에 접근하는 디렉터리입니다. 보고서 애플리케이션용으로 준비된 디렉터리에 새 파일 시스템을 마운트합니다.
sudo mount /dev/xvdf /srv/reports
원본 장치, 파일 시스템 및 마운트 지점을 확인합니다.
findmnt /srv/reports
/dev/xvdf, ext4, /srv/reports를 확인합니다. 가상 데이터로 CSV 보고서를 생성합니다. sudo tee는 관리자 소유 파일 시스템에 쓰며, 구분자를 따옴표로 감싼 here-document는 두 줄을 그대로 유지합니다.
sudo tee /srv/reports/report.csv <<'CSV'
period,total
Q1,320
CSV
파일을 다시 읽습니다.
cat /srv/reports/report.csv
LabEx 터미널로 돌아갑니다.
exit
AWS View에서 recovery-server를 선택하고 Read volume report를 클릭합니다. HTTP 200과 CSV 텍스트 period,total 및 Q1,320을 확인합니다. 이 응답은 애플리케이션이 마운트된 볼륨의 파일을 읽을 수 있음을 보여 줍니다.
이 실습의 마운트는 수동입니다. 재부팅하면 수동 마운트가 자동으로 복원되지 않습니다. 운영 환경에서는 일반적으로 항목을 테스트한 뒤 /etc/fstab에 파일 시스템 UUID를 설정합니다.
일관된 스냅샷 만들기
이 단계에서는 파일 시스템 접근을 일시 중지하고 원본 볼륨을 백업합니다.
EBS 스냅샷은 특정 시점의 볼륨 백업입니다. 백업은 리소스 상태가 성공인 것뿐 아니라 필요한 데이터를 포함해야 합니다. AWS는 스냅샷 생성 안내서에서 설명하는 것처럼 일관성을 위해 쓰기를 일시 중지하거나 볼륨을 마운트 해제하도록 권장합니다. 이 실습에서는 백업 전에 데이터 파일 시스템의 마운트를 해제합니다.
인스턴스에 연결합니다.
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
원본 파일 시스템의 마운트를 해제하여 쓰기를 반영하고 파일 시스템 접근을 중단합니다.
sudo umount /srv/reports
LabEx 터미널로 돌아갑니다.
exit
원본 볼륨의 스냅샷을 생성합니다. ID를 저장하고 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)
스냅샷 생성은 비동기 작업입니다. 완료될 때까지 기다립니다.
aws ec2 \
wait snapshot-completed \
--snapshot-ids "$SNAPSHOT_ID"
상태와 원본 볼륨을 확인합니다.
aws ec2 \
describe-snapshots \
--snapshot-ids "$SNAPSHOT_ID" \
--query 'Snapshots[].{Snapshot:SnapshotId,State:State,SourceVolume:VolumeId}'
completed와 예상한 원본 볼륨을 확인합니다. AWS View를 새로 고침하여 스냅샷을 확인합니다. 파일을 의도적으로 삭제한 뒤 복원을 통해 내용을 테스트합니다.
파일 실수 삭제의 영향 관찰하기
이 단계에서는 원본 볼륨에서 가상 보고서를 제거하고 애플리케이션에 보고서가 없는 상태를 관찰합니다.
다시 연결하고 원본 볼륨을 다시 마운트합니다.
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo mount /dev/xvdf /srv/reports
이 연습을 위해 생성한 가상 파일만 삭제합니다.
sudo rm /srv/reports/report.csv
LabEx 터미널로 돌아갑니다.
exit
AWS View에서 recovery-server를 선택하고 Read volume report를 클릭합니다. 요청은 여전히 HTTP 200을 반환하지만 이제 report는 null입니다. 애플리케이션은 실행 중이고 필요한 파일이 없는 상태입니다. 이를 통해 스토리지 내용 문제와 서버 중지 문제를 구분할 수 있습니다.
스냅샷은 삭제 전에 생성되었습니다. 원본 볼륨을 수정하지 않고 이전 보고서를 포함하는 새 볼륨을 제공할 수 있습니다.
스냅샷에서 새 볼륨 복원하기
이 단계에서는 백업을 별도의 볼륨으로 복원하고 애플리케이션을 복구된 파일 시스템으로 전환합니다.
복원은 새 볼륨을 생성하며 기존 볼륨의 변경 사항을 되돌리지 않습니다. 완료된 스냅샷을 사용하여 인스턴스의 가용 영역에 대체 볼륨을 생성합니다. 공식 복원 안내서에서 이 교체 절차를 설명합니다.
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)
준비될 때까지 기다립니다.
aws ec2 \
wait volume-available \
--volume-ids "$RESTORED_VOLUME_ID"
두 번째 데이터 장치로 연결합니다.
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"
대체 볼륨과 스냅샷의 관계를 확인합니다.
aws ec2 \
describe-volumes \
--volume-ids "$RESTORED_VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Snapshot:SnapshotId}'
in-use와 저장한 스냅샷 ID를 확인합니다. 애플리케이션 마운트를 전환하기 위해 연결합니다.
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
원본 파일 시스템의 마운트를 해제합니다.
sudo umount /srv/reports
이 실습에서 /dev/xvdg로 표시되는 복구된 장치를 확인합니다.
sudo lsblk -f /dev/xvdg
백업에서 복사된 ext4 파일 시스템이 이미 포함되어 있습니다. 이 장치를 포맷하지 마세요. 포맷하면 복원된 데이터를 덮어씁니다. 기존 파일 시스템을 애플리케이션의 보고서 디렉터리에 마운트합니다.
sudo mount /dev/xvdg /srv/reports
현재 사용 중인 원본 장치를 확인합니다.
findmnt /srv/reports
/dev/xvdg를 확인합니다. 복구된 보고서를 읽습니다.
cat /srv/reports/report.csv
원래 두 줄인 period,total과 Q1,320이 예상 결과입니다. LabEx 터미널로 돌아갑니다.
exit
AWS View에서 Refresh resources를 클릭하고 recovery-server를 선택한 다음 Read volume report를 클릭합니다. HTTP 200과 원본 CSV 텍스트를 확인합니다. 성공적인 복원 테스트는 백업에 사용 가능한 애플리케이션 데이터가 포함되어 있음을 증명합니다.
복구 리소스 제거하기
이 단계에서는 두 데이터 볼륨, 스냅샷 및 인스턴스를 정리합니다.
연결하여 복구된 파일 시스템의 마운트를 해제합니다.
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo umount /srv/reports
exit
복구된 볼륨의 연결을 해제합니다.
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"
원본 파일 시스템은 복원 중 마운트 해제했습니다. 원본 볼륨도 연결 해제합니다.
aws ec2 \
detach-volume \
--volume-id "$VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdf
aws ec2 \
wait volume-available \
--volume-ids "$VOLUME_ID"
연결 해제된 두 연습용 볼륨을 삭제합니다.
aws ec2 \
delete-volume \
--volume-id "$RESTORED_VOLUME_ID"
aws ec2 \
delete-volume \
--volume-id "$VOLUME_ID"
복원 테스트 후 연습용 백업을 삭제합니다.
aws ec2 \
delete-snapshot \
--snapshot-id "$SNAPSHOT_ID"
서버를 종료하고 최종 상태를 기다립니다.
aws ec2 \
terminate-instances \
--instance-ids "$INSTANCE_ID"
aws ec2 \
wait instance-terminated \
--instance-ids "$INSTANCE_ID"
인스턴스가 종료되었는지 확인합니다.
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
이름을 사용하여 연습용 볼륨과 백업을 나열합니다.
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'
두 목록 모두 []이어야 합니다. AWS View를 새로 고침하여 연습용 볼륨과 스냅샷이 없어졌고 서버가 더 이상 실행 중인 대상이 아닌지 확인합니다. 준비된 네트워크와 키 페어는 그대로 유지합니다.
요약
EBS 스냅샷으로 보고서 볼륨을 백업하고 파일 삭제의 영향을 관찰한 뒤 백업에서 별도의 볼륨을 복원했습니다. 복구된 기존 파일 시스템을 포맷하지 않고 마운트하여 원래 애플리케이션 데이터를 확인했습니다. 마지막으로 두 데이터 볼륨, 스냅샷 및 인스턴스를 제거했습니다.
