SOA-C03 07/16 — 백업·복원·재해 복구
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 복구의 목표를 먼저 정한다
RPO는 감수할 수 있는 데이터 손실의 시간 범위이고, RTO는 기능을 복구해야 하는 목표 시간이다. 백업 간격은 RPO에 영향을 주며, 복원·설정·검증·트래픽 전환 시간은 RTO에 영향을 준다.
예를 들어 업무 목표가 RPO 15분·RTO 2시간이라면 하루 한 번 snapshot만으로는 충분한 복구 지점을 확보하기 어렵다. 반대로 최근 지점으로 복원할 수 있어도 새 환경 준비에 반나절이 걸리면 RTO를 만족하지 못한다. 이 수치는 관계 설명용 예시다.
복구 계획에는 무엇을 어느 시점으로, 어느 환경에, 어떤 순서로 복원하고, 무엇을 확인한 뒤 서비스로 연결할지가 있어야 한다.
2. 백업 정책·실행·복구 지점을 연결한다
AWS Backup은 backup plan으로 일정·보존·복사 정책을 정의하고 resource selection으로 대상을 지정한다. 실제 backup job이 성공해 recovery point가 생겼는지 확인해야 보호 상태를 판단할 수 있다. tag 기반 선택은 누락된 tag 때문에 대상을 놓칠 수 있다.
| 관찰 대상 | 확인 내용 |
|---|---|
| Plan | 실행 주기·시작/완료 창·보존 정책 |
| Selection | 예상 리소스가 실제 대상에 포함되는가 |
| Job | 성공·실패·부분 결과와 오류 |
| Recovery point | 필요한 시점·리소스·암호화 키·접근 가능성 |
| Copy | 다른 account·Region의 복사 작업 완료 여부 |
| Restore | 실제 복원과 기능 검증 결과 |
서비스별로 continuous backup·cold storage·cross-account copy 지원이 다르다. 하나의 서비스에서 가능한 기능을 모든 리소스에 적용하지 않는다. AWS Backup
복사 정책이 있다는 사실과 목적지에 복사본이 존재한다는 사실도 다르다. 원본 account·Region 장애 시 사용할 IAM·KMS·네트워크·capacity를 복원 환경에서 확인한다.
3. EC2·EBS snapshot의 복원 단위
EBS snapshot은 볼륨 데이터를 보존하고 그 시점의 새 볼륨을 만드는 원천이 된다. Snapshot을 만들었다고 애플리케이션 메모리·진행 중 transaction·외부 의존성까지 함께 보존되는 것은 아니다. EBS snapshots
여러 볼륨을 쓰는 DB는 논리적으로 일관된 복구 지점이 필요하다. 애플리케이션에 맞는 flush·freeze 또는 지원되는 VSS 같은 절차를 확인한다. Windows VSS 기반 snapshot은 VSS-aware 애플리케이션의 일관성을 위한 선택이며 모든 OS에 그대로 적용하지 않는다. VSS application-consistent snapshots
EC2 복구는 boot할 이미지·볼륨뿐 아니라 instance profile, subnet·security group, secret·설정, DNS·LB 등록을 다시 연결하는 작업이다. 새 instance가 running인 것과 원래 업무를 처리하는 것은 별도로 검증한다.
4. RDS와 DynamoDB PITR
PITR은 원하는 과거 시점의 데이터를 복원한다. 사고 발견 시각보다 먼저 잘못된 쓰기가 시작됐을 수 있으므로 로그·감사 기록에서 첫 손상 시점을 찾는다.
RDS DB instance의 PITR은 새 DB instance를 생성한다. 복원 가능한 시간 범위를 확인하고 새 DB의 network·parameter·접근 설정과 endpoint 전환을 검토한다. 기존 DB를 그대로 과거로 되감았다고 가정하지 않는다. RDS PITR
DynamoDB PITR도 새 table로 복원한다. 복원 후 auto scaling·IAM·alarm·tag·Streams·TTL·PITR 설정 등을 다시 구성해야 한다. table이 Active여도 애플리케이션이 새 이름을 사용하지 않거나 Streams 소비가 연결되지 않으면 업무 복구는 끝나지 않는다. DynamoDB 복원
복원 전후에 다음을 비교한다.
- 선택 시점과 예상 데이터 누락 범위.
- 핵심 row/item·합계·참조 관계.
- 필요한 읽기·쓰기 기능과 접근 권한.
- 새 endpoint/table로의 전환과 재연결.
- 사고 후 정상적으로 발생한 데이터를 어떻게 재처리할지.
5. Versioning은 과거 버전을 남기는 기능이다
S3 Versioning은 같은 key의 여러 버전을 유지한다. 버전 사용 bucket에서 일반적인 삭제는 delete marker를 만들며 이전 버전은 별도로 남을 수 있다. 특정 version ID를 영구 삭제하는 행위와 구분한다. Lifecycle의 noncurrent version 만료는 과거 버전을 제거하므로 보존 요구와 함께 검토한다. S3 Versioning
FSx에서는 제품별 기능으로 읽는다. Windows File Server의 shadow copy는 파일·폴더의 이전 시점을 복구하는 수단이다. 파일시스템의 저장 공간을 사용하므로 독립된 전체 파일시스템 백업이나 다른 Region의 복사본과 같은 것으로 취급하지 않는다. FSx shadow copies
현재 plan의 “S3·FSx versioning”은 각 서비스의 이전 버전·snapshot 복원 기능으로 연결한다. FSx 모든 제품에 S3식 version ID가 있다고 설명하지 않는다.
6. DR 전략은 준비된 구성의 양이 다르다
| 전략 | 평상시 준비 | 장애 시 핵심 작업 |
|---|---|---|
| Backup and restore | 데이터·구성 백업 | 환경 생성·데이터 복원·연결 |
| Pilot light | 핵심 데이터 계층 등 최소 구성 | 나머지 계층 배치·기동·확장 |
| Warm standby | 축소된 기능 가능한 환경 | 용량 확대·트래픽 전환 |
| Active/active | 여러 환경이 실제 요청 처리 | 장애 환경 제외·일관성·잔여 capacity 확보 |
대체로 더 많은 환경을 항상 운영할수록 복구 시간을 줄일 여지가 생기지만 비용과 운영 복잡성이 증가한다. 전략 이름만으로 특정 RTO·RPO를 보장하지 않는다. 데이터 복제 지연·전환 절차·의존성에 따라 실제 결과가 달라진다. AWS DR 전략
복제가 있어도 잘못된 삭제·데이터 손상이 다른 환경에 전파될 수 있다. 가용성을 위한 복제와 과거 시점으로 돌아가기 위한 백업은 함께 설계한다.
7. 복원 시험과 업무 검증
AWS Backup restore testing은 복원 가능성과 소요 시간을 주기적으로 확인하고, validation을 연결할 수 있다. 복원된 테스트 자원의 정리와 비용까지 확인한다. Restore testing
복구 연습은 production 트래픽·실제 알림·외부 결제를 분리한 환경에서 수행하도록 설계한다. 확인 항목은 restore job 성공, 데이터 검증, 앱 기동, secret·KMS 접근, DNS·LB 전환 가능성이다. 여기서는 실습을 실행하지 않았으며 절차를 설명한다.
8. 완성된 운영 적용 — 잘못된 대량 데이터 수정
- 잘못된 쓰기의 계속 실행을 막고 현재 증거를 보존한다.
- 감사 기록으로 시작 시각을 좁혀 오염 이전 recovery point를 고른다.
- 원본을 보존한 채 별도 DB/table로 복원한다.
- 정상 데이터와 손상 데이터를 비교하고 사고 후 정상 업무의 재처리 범위를 정한다.
- 검증된 환경으로 연결을 바꾸고 실제 읽기·쓰기 결과를 확인한다.
- 달성한 데이터 손실 범위와 복구 시간을 기록한다.
- 권한·배포·백업 검증을 고쳐 같은 사고의 영향과 복구 시간을 줄인다.
시험에서는 RPO·RTO·비용 조건에 맞는 복원 방식과 DR 전략을 선택한다. 실제 운영의 완료 기준은 backup 존재가 아니라 필요한 시점의 데이터로 업무가 다시 작동하는 것이다. 범위: Domain 2 Task 2.3.
계획과 연결
-
ID:
07-backup-restore-and-disaster-recovery -
의존:
06-scaling-load-balancing-and-resilience -
결정 축: RPO·RTO·비용·복구 범위를 복구 지점, 복원 방식, 버전 관리와 DR 운영 절차에 연결한다.
-
범위: AWS Backup, EC2·RDS·EBS·S3·DynamoDB backup/snapshot, point-in-time restore, S3·FSx versioning, backup and restore·pilot light·warm standby·active/active.
-
시험 매핑: Domain 2, Task 2.3.