Aurora MySQL 백업 모델: cluster snapshot, continuous backup, PITR의 차이

Aurora MySQL에서 백업을 이해하려면 세 가지 질문을 분리해야 한다. 어떤 데이터를 계속 보존하는가, 어떤 복구 지점을 장기간 남기는가, 실제 사고에서 어느 시점으로 새 클러스터를 만드는가라는 질문이다. 각각 연속 자동 백업, 수동 클러스터 스냅샷, 시점 복구(PITR)와 연결된다.

자동 백업이 켜져 있다는 사실만으로 복구 준비가 끝나지는 않는다. 잘못된 DELETE가 반영되기 전의 시점을 찾아야 하고, 복구 가능한 시간 범위를 확인해야 하며, 새 클러스터의 연결·권한·설정을 검증한 뒤 애플리케이션을 전환해야 한다. 이 글은 Aurora MySQL의 관리형 백업 모델을 중심으로 이 경계를 설명한다. 일반 RDS for MySQL의 DB 인스턴스 백업과 혼동하지 않는다.

검증 범위: AWS 공식 문서에서 서비스 동작과 API 필드를 확인했다. SQL 예제는 Community MySQL 8.0의 폐기용 환경에서 실행한 시간 판정 실습이다. 실제 Aurora 클러스터 생성, 스냅샷 복원, PITR 소요 시간 및 데이터 복구 성공률을 측정한 결과는 아니다. AWS CLI 예제는 대상 환경에서 값을 바꾸어 실행하는 읽기 전용 조회 절차이며, 이 글의 작성 환경에서는 실행하지 않았다.

1. 세 용어는 경쟁하는 백업 제품이 아니다

구분	무엇을 의미하는가	복구 지점과 보존	운영상 용도
연속 자동 백업	클러스터 볼륨의 변경을 지속적으로 보존하는 관리형 백업 체계	설정한 보존 기간 안의 복구 가능 구간	최근 장애·오작업에 대한 PITR 기반
수동 클러스터 스냅샷	특정 시점의 클러스터 볼륨을 복원할 수 있는 명시적 복구 지점	자체 만료 없이 보존되며 명시적 삭제·관리 정책에 주의	배포 전 기준점, 장기 보관, 복사·공유 기반
PITR	보존된 백업 데이터로 지정 시점의 새 클러스터를 만드는 복원 작업	실제 earliest/latest 경계 안의 시점	사고 트랜잭션 반영 전으로 복구

PITR은 연속 백업과 별개로 수집하는 세 번째 백업 파일이 아니다. 연속적으로 보존된 이력을 이용하는 복원 방식이다. 반대로 수동 스냅샷 하나를 보관한다고 해서 그 이후 모든 시점으로 돌아갈 수 있는 연속 이력까지 무기한 보장되는 것은 아니다.

또한 “전체 클러스터 복구 지점”과 “백업을 매번 전체 복사하는가”는 서로 다른 질문이다. 스냅샷은 사용자가 클러스터 전체를 복원할 수 있는 단위로 이해해야 한다. 내부 저장 방식이나 저장 요금은 자동 백업의 증분 변경 보존과 구분하여 공식 저장량 지표로 확인한다.

2. 연속 백업: 백업 창과 복구 가능 시점은 다르다

Aurora의 자동 백업은 연속적이고 증분 방식이며 Amazon S3에 저장된다. PITR 문서에서는 로그 레코드를 지속적으로 S3에 업로드한다고 설명한다. 운영자가 직접 datadir를 복사하거나 mysqlbinlog로 로그를 이어 붙이는 구조가 아니다. AWS는 백업 데이터 기록 과정에 데이터베이스 서비스 중단이나 성능 영향이 없다고 설명한다. 이는 관리형 백업 동작에 대한 설명이지, 애플리케이션의 모든 부하나 복구 이후 성능에 대한 보장은 아니다.

클러스터의 자동 백업 보존 기간은 1~35일로 설정한다. 기본값은 1일이며 Aurora에서는 자동 백업을 비활성화할 수 없다. 보존 기간은 DB 인스턴스마다 정하는 값이 아니라 클러스터 수준의 정책이다. 신규 생성 시 기본값과 복원 시 원본 보존 기간을 상속하는 동작도 구별해야 한다.[1]

백업 창은 하루에 한 번만 복구할 수 있다는 뜻이 아니다

Preferred backup window는 보존 기간 안에서 유지할 일일 시스템 백업을 만드는 시간 창이다. 변경 이력의 연속 보존이 이 시간 동안에만 수행되는 것은 아니다. 따라서 다음 두 해석은 모두 잘못이다.

“백업 창이 새벽이므로 오후 장애에서는 새벽으로만 돌아갈 수 있다.”
“연속 백업이므로 사고 직전의 마지막 커밋까지 항상 즉시 복원할 수 있다.”

첫 번째는 PITR을 일일 스냅샷 복원으로 축소한 해석이다. 두 번째는 원본의 현재 상태와 복구 서비스가 제공하는 최신 복구 지점을 동일시한 해석이다.

실제 경계는 API의 시간 필드로 확인한다

EarliestRestorableTime: 현재 복구할 수 있는 가장 이른 시점이다.
LatestRestorableTime: 현재 복구할 수 있는 가장 최근 시점이다.
BackupRetentionPeriod: 보존 정책이며, 현재 모든 시점이 실제로 복구 가능한지를 증명하는 값은 아니다.

AWS는 활성 클러스터의 최신 복구 가능 시점이 통상 현재 시각에서 5분 이내라고 설명한다. 통상적인 설명을 고정 RPO 보장이나 SLA로 바꾸어서는 안 된다. 사고 시에는 실제 필드 값을 저장하고, 원본 쓰기 시점·사고 시점·복구 목표 시점을 같은 시간대에서 대조한다. 복원 중 등으로 경계가 NULL이면 “제한이 없다”가 아니라 복구 가능 여부를 아직 판정할 수 없는 상태로 처리한다.[1][2]

flowchart TD
    A[원본 Aurora 클러스터의 변경] --> B[연속 자동 백업과 로그 보존]
    A --> C[수동 클러스터 스냅샷]
    B --> D[복구 가능 구간 안의 목표 시점 선택]
    D --> E[PITR로 새 클러스터 생성]
    C --> F[스냅샷 시점의 새 클러스터 생성]
    E --> G[Writer와 네트워크 및 설정 확인]
    F --> G
    G --> H[업무 데이터와 애플리케이션 검증]
    H --> I[원본 쓰기 차단과 연결 전환]

그림의 연속 백업 경로는 Aurora 관리형 경로다. MySQL의 사용자용 binary log를 활성화하여 외부 복제에 사용하는 경로와 동일하지 않다. Aurora 네이티브 PITR을 위해 사용자가 binlog를 직접 켜고 수집해야 한다고 안내해서는 안 된다.

3. 클러스터 스냅샷: 오래 남기는 기준점

Aurora DB cluster snapshot은 개별 테이블이나 스키마가 아니라 클러스터 전체 스토리지 볼륨을 백업하는 단위다. 특정 스키마만 필요하더라도 스냅샷 복원 API에서 해당 스키마만 골라 기존 운영 클러스터에 덮어쓰는 방식은 아니다. 별도 클러스터를 복원한 뒤 필요한 객체를 논리적으로 추출하고, 스키마 의존성과 데이터 충돌을 검토하여 반입한다.[3]

수동 스냅샷은 자동 백업 보존 기간이 지나도 자체 만료되지 않는다. 다만 이것이 삭제 불가능이나 영구 복구 가능을 뜻하지는 않는다. 삭제 권한, AWS Backup 등 상위 정책, 암호화 키 접근성, 엔진 버전 지원 조건을 함께 관리해야 한다. 장기 보존본은 이름과 생성일뿐 아니라 소유자, 보존 목적, 삭제 승인 기준을 기록한다.

배포 전 스냅샷의 의미

배포 전 수동 스냅샷은 사람이 명확하게 식별할 수 있는 기준점이라는 장점이 있다. 그러나 스냅샷을 자주 만든다고 PITR의 최신 경계가 더 빨리 전진하거나 복구 시간이 반드시 짧아지는 것은 아니다. AWS도 연속·증분 백업 때문에 복원 시간을 개선할 목적으로 잦은 스냅샷을 만들 필요는 없다고 설명한다.[1]

배포 이후 데이터가 추가되었다면 배포 전 스냅샷으로 전체 서비스를 되돌리는 순간 정상적인 신규 주문까지 잃을 수 있다. 스냅샷의 존재와 되돌리기 결정은 별개다. 업무 변경을 선별 복구할지, 전체 클러스터를 되돌릴지, 배포만 롤백하고 데이터는 보정할지 먼저 판단한다.

클러스터 삭제와 보존은 별도 결정이다

클러스터 삭제 시 자동 백업을 유지하도록 선택할 수 있지만, retained automated backup도 원래 보존 정책에 따라 결국 만료된다. 삭제 후 새로운 스냅샷과 로그가 계속 생성되는 것이 아니다. 최종 스냅샷은 이와 달리 자체 만료되지 않는 복구 지점이다. 삭제 계획에서는 자동 백업 보존 여부와 최종 스냅샷 생성을 각각 확인한다.[4]

장기 보존을 요구하면서 “삭제할 때 자동 백업을 남겼다”만 기록하면 요구 기간을 충족하지 못할 수 있다. 계정 침해나 리전 전체 장애까지 고려한다면 별도 계정·리전 복사, KMS 키 정책, 복원 권한 검증도 추가한다. 원본과 같은 관리 경계의 백업만으로 모든 재해를 방어한다고 가정하지 않는다.

4. PITR: 데이터 시간을 되돌리되 원본을 덮어쓰지 않는다

스냅샷 복원과 PITR 모두 일반적인 복원 절차에서는 새 DB 클러스터를 생성한다. 원본 클러스터가 제자리에서 이전 상태로 바뀌거나, 원본 endpoint가 자동으로 새 클러스터를 가리키는 작업이 아니다.[2][3]

이 특성은 사고 분석과 비교 검증에 유리하다. 원본을 보존한 채 복구본에서 피해 범위와 정상 거래를 조사할 수 있다. 반면 실제 서비스 재개까지는 추가 단계가 필요하다.

사고 경계 확정: 애플리케이션 감사 이력, 배포 이력, 업무 식별자를 이용해 문제가 반영되기 전 시점을 찾는다. SQL 실행 시작 시각만으로 커밋 경계를 확정하지 않는다.
시간 범위 검사: 목표 시점이 조회한 복구 가능 구간에 포함되는지 확인한다. API 요청에서는 UTC 시각을 명시한다.
새 클러스터 복원: snapshot identifier 또는 source cluster와 목표 시점을 지정한다. 복원 대상 식별자는 원본과 분리한다.
연결 가능한 Writer 준비: CLI/API의 클러스터 복원은 DB 인스턴스 생성과 별개다. 클러스터 준비 뒤 create-db-instance 등으로 첫 Writer를 명시적으로 만든다. 콘솔의 통합 복원 흐름과 혼동하지 않는다.
데이터·설정 검증: 사고 변경이 없고 기대하는 정상 변경이 존재하는지 검사한다. 네트워크, 파라미터 그룹, 권한, 연결 설정도 함께 확인한다.
쓰기 경계와 전환: 원본과 복구본에 동시에 업무 쓰기가 들어가지 않도록 차단하고, 애플리케이션의 연결 대상을 바꾼다. 연결 풀·DNS 캐시·배치 작업·외부 소비자를 함께 전환한다.

복구 중에도 원본에서 정상 거래를 계속 받았다면 복구 목표 시점 이후의 변경을 어떻게 처리할지 결정해야 한다. 무조건 새 클러스터로 연결만 바꾸면 이 기간의 정상 거래가 서비스에서 사라질 수 있다. 데이터 보정이나 재입력에는 멱등성, 업무 순서, 외부 결제·알림과의 일치 여부가 포함되어야 한다.

데이터가 복원되어도 운영 환경이 같지는 않다

공식 문서는 별도로 지정하지 않으면 복구 클러스터에 기본 파라미터 그룹이 연결된다고 설명한다. 사용자 정의 DB cluster parameter group과 DB parameter group을 보존하고 호환되는 그룹을 명시적으로 선택해야 한다. VPC security group도 실제 연결 상태를 확인해야 한다.[2][3]

복구 전 설정 목록에는 subnet group, 보안 그룹, KMS 키, 엔진 버전, 인스턴스 클래스, 로그 내보내기, 모니터링, IAM 연계, 인증 정보 전달 경로 등을 포함한다. 이 중 어떤 값이 상속·기본 적용·별도 생성되는지는 해당 복원 API와 엔진 조건으로 확인한다. 백업 파일 하나가 네트워크와 애플리케이션 구성 전체를 보관한다고 가정하지 않는다.

5. 조회 절차와 복구 시점 판정 실습

운영 클러스터의 실제 복구 경계 조회

다음 명령은 조회 전용이다. AWS CLI 인증과 조회 권한을 준비하고 REGION, CLUSTER를 대상 값으로 변경한다. 샘플 식별자는 실제 환경을 가리키지 않는다. 반환되는 timestamp의 시간대도 함께 보존한다.

REGION='ap-northeast-2'
CLUSTER='example-aurora-cluster'

aws rds describe-db-clusters \
  --region "$REGION" \
  --db-cluster-identifier "$CLUSTER" \
  --query 'DBClusters[0].{Status:Status,RetentionDays:BackupRetentionPeriod,Earliest:EarliestRestorableTime,Latest:LatestRestorableTime,BackupWindow:PreferredBackupWindow}' \
  --output json

aws rds describe-db-cluster-snapshots \
  --region "$REGION" \
  --db-cluster-identifier "$CLUSTER" \
  --snapshot-type manual \
  --query 'DBClusterSnapshots[].{Id:DBClusterSnapshotIdentifier,Time:SnapshotCreateTime,Status:Status,Encrypted:StorageEncrypted}' \
  --output table

두 명령의 결과를 합쳐 읽는다. 첫 번째는 연속 복구 구간과 정책이고, 두 번째는 수동 복구 지점 목록이다. 수동 스냅샷이 없더라도 연속 자동 백업의 PITR이 가능할 수 있으며, 수동 스냅샷이 있어도 자동 백업 보존 범위를 벗어난 임의 시각의 PITR을 보장하지는 않는다. 삭제한 클러스터의 보존 백업은 활성 클러스터 조회와 구분하여 retained automated backup 목록에서 확인한다.

시간 조건은 SQL로 점검하되 복원 성공 판정과 구분한다

아래 입력은 전부 설명용으로 정한 시각이다. AWS API를 조회한 실제 값이 아니다. 모든 DATETIME 값을 UTC로 해석하고, KST 표시는 시간대 테이블에 의존하지 않는 고정 오프셋 변환으로 계산한다. 세 가지 후보와 경계 미확인 상황을 비교한다.

WITH bounds AS (
    SELECT CAST('2026-10-01 00:00:00' AS DATETIME) AS earliest_utc,
           CAST('2026-10-04 00:00:00' AS DATETIME) AS latest_utc
), candidates AS (
    SELECT 'before_window' AS case_name,
           CAST('2026-09-30 23:59:59' AS DATETIME) AS target_utc
    UNION ALL
    SELECT 'inside_window', CAST('2026-10-03 23:55:00' AS DATETIME)
    UNION ALL
    SELECT 'after_window', CAST('2026-10-04 00:01:00' AS DATETIME)
), checks AS (
    SELECT c.case_name, c.target_utc, b.earliest_utc, b.latest_utc
    FROM candidates c CROSS JOIN bounds b
    UNION ALL
    SELECT 'unknown_bound', CAST('2026-10-03 23:55:00' AS DATETIME),
           earliest_utc, NULL
    FROM bounds
)
SELECT case_name,
       target_utc,
       CONVERT_TZ(target_utc, '+00:00', '+09:00') AS target_kst,
       CASE
           WHEN earliest_utc IS NULL OR latest_utc IS NULL THEN 'UNKNOWN'
           WHEN target_utc < earliest_utc THEN 'TOO_OLD'
           WHEN target_utc > latest_utc THEN 'TOO_NEW'
           ELSE 'IN_WINDOW'
       END AS window_check
FROM checks
ORDER BY case_name;

실행 결과(MySQL 8.0.x):

다음은 MySQL 8.0.46에서 실행한 출력이다. 긴 SQL 입력 부분만 줄였으며 결과의 행과 열은 모두 표시했다.

mysql> WITH bounds AS (...) ... ORDER BY case_name;
+---------------+---------------------+---------------------+--------------+
| case_name     | target_utc          | target_kst          | window_check |
+---------------+---------------------+---------------------+--------------+
| after_window  | 2026-10-04 00:01:00 | 2026-10-04 09:01:00 | TOO_NEW      |
| before_window | 2026-09-30 23:59:59 | 2026-10-01 08:59:59 | TOO_OLD      |
| inside_window | 2026-10-03 23:55:00 | 2026-10-04 08:55:00 | IN_WINDOW    |
| unknown_bound | 2026-10-03 23:55:00 | 2026-10-04 08:55:00 | UNKNOWN      |
+---------------+---------------------+---------------------+--------------+
4 rows in set (0.00 sec)

IN_WINDOW는 이 실습의 시간 범위 조건을 만족한다는 뜻일 뿐이다. 특정 시점이 사고 이전인지, 키와 권한이 유효한지, 복구 요청이 성공하는지, 업무 행이 정확히 복구되는지까지 증명하지 않는다. 경계와 정확히 같은 시각의 요청 허용 여부도 실제 API 제약과 응답으로 확인하고, 사고 복구에서는 근거가 있는 내부 시점을 선택하는 편이 안전하다.

특히 LatestRestorableTime과 현재 시각의 차이는 백업의 최신성을 관찰하는 신호다. 실제 데이터 손실량은 선택한 복구 시점 이후의 유효 업무 변경 중 복구·보정하지 못한 부분이다. 두 개념을 같은 숫자로 보고하지 않는다.

6. 흔한 실패 모드와 운영 판단

상황	잘못된 결론	확인하거나 바꿔야 할 판단
최신 백업으로 돌아가려 한다	가장 최신이면 항상 가장 안전하다	논리적 삭제가 이미 반영된 최신 시점은 피해를 그대로 포함한다
35일 보존을 설정했다	한 달 전 모든 시점이 지금 즉시 가능하다	실제 earliest/latest 필드와 클러스터 이력으로 확인한다
스냅샷 상태가 정상이다	애플리케이션 복구도 검증되었다	별도 복원 후 데이터, 설정, 애플리케이션 접근을 검증한다
클러스터가 `available`이다	서비스 RTO가 끝났다	Writer, 연결, 데이터 검증과 전환 완료 시각까지 측정한다
원본을 삭제하며 자동 백업을 남겼다	장기 보존이 완료되었다	자동 백업 만료와 최종 스냅샷 수명은 다르다
Reader 또는 다중 AZ가 있다	오삭제도 자동 방어된다	고가용성은 정상적으로 커밋된 잘못된 변경도 전달한다
스냅샷을 S3로 내보냈다	동일한 스냅샷 복원 경로로 바로 돌아온다	분석용 내보내기와 네이티브 클러스터 복원을 구분한다

Aurora의 Backtrack은 지원 조건 안에서 클러스터를 이전 시점으로 되감는 별도 기능이다. 이 글의 새 클러스터 복원 절차와 혼용하지 않는다. 지원 엔진·리전·설정 조건과 되감기 동안의 운영 영향을 별도로 확인해야 하며, 장기 스냅샷 보존의 대체재로 보지 않는다.

7. 보존 비용과 복구 훈련을 함께 관리한다

백업 보존 일수를 늘리면 더 오래된 사고를 복구할 여지가 생기지만, 변경량과 스냅샷 보존에 따라 저장량이 달라진다. 원본 크기에 보존 일수를 단순히 곱한 값을 청구량으로 사용하지 않는다. 공식 지표의 의미는 다음과 같다.[5]

BackupRetentionPeriodStorageUsed: 현재 자동 백업에 사용되는 저장량이다. 클러스터 크기와 보존 기간 중 변경량의 영향을 받으며 무료 제공량을 뺀 값이 아니다.
SnapshotStorageUsed: 자동 백업 보존 기간 밖에서 보관하는 수동 스냅샷의 저장량을 관찰한다.
TotalBackupStorageBilled: 무료 제공량을 고려한 청구 대상 백업 저장량이다.

이 지표들은 바이트 단위의 저장량 지표이지 초당 처리량이나 복구 지연이 아니다. 공식 문서의 일별 데이터 포인트 및 집계 규칙을 따라 조회한다. 특히 스냅샷별 데이터 포인트가 있는 지표를 단일 최신 값으로만 읽으면 전체 저장량을 놓칠 수 있다. 비용 검토는 실제 청구와 리전별 요금을 함께 확인한다.

복구 훈련에서는 다음 시간을 따로 기록한다. 사고 판단과 목표 시점 확정, 클러스터 복원 요청부터 준비까지, Writer와 연결 준비, 데이터·애플리케이션 검증, 실제 트래픽 전환까지의 시간이다. 클러스터 생성 시간만으로 서비스 RTO를 보고하면 가장 오래 걸리는 업무 검증과 전환을 누락할 수 있다.

운영 체크리스트

8. 정리

Aurora MySQL의 연속 백업은 최근 변경 이력을 보존하는 기반, 수동 클러스터 스냅샷은 명시적으로 오래 남길 수 있는 복구 지점, PITR은 그 이력에서 선택한 시점의 새 클러스터를 만드는 작업이다. 이 구분이 명확해야 보존 정책, 사고 경계, 실제 서비스 전환을 하나의 복구 계획으로 연결할 수 있다.

다음 복구 설계에서는 “복원 API가 성공했다”에서 멈추지 않고, 복구본에서 어떤 업무 불변식을 검사하며 어떤 조건에서 서비스 전환을 승인할지 구체화해야 한다. 백업의 가치는 보유 목록이 아니라 검증된 복원과 전환 능력으로 판단한다.