DynamoDB 백업과 Point-in-Time Recovery 완전 가이드

DynamoDB는 데이터를 두 가지 방식으로 보호합니다. 온디맨드 백업은 여러분이 직접 찍어 무기한 보관하는 전체 스냅샷입니다. 특정 시점 복구(PITR)는 롤링 윈도 안의 어느 초로든 테이블을 복원하게 해주는 연속적, 자동 백업입니다. 둘 다 새 테이블로 복원합니다 — 실행 취소 버튼이 아니라 복구 도구입니다.

감사 로그에는 이것이 타협 불가입니다. 그것은 불변의 규정 준수 기록이므로, 이벤트를 다시 쓰는 잘못된 마이그레이션이나 실수로 인한 대량 삭제는 실수 직전의 순간으로 복구 가능해야 합니다.

DynamoDB 백업과 특정 시점 복구는 어떻게 작동하나요?

DynamoDB는 두 가지 백업 유형을 제공합니다. 특정 시점 복구(PITR)는 연속적 자동 백업을 찍어, 설정 가능한 1~35일 윈도 안의 어느 초로든 복원하게 해줍니다. 온디맨드 백업은 무기한 보관되는 수동 전체 스냅샷입니다. 둘 다 원본 위가 아니라 새 테이블로 복원하므로, 제자리 실행 취소가 아니라 복구 도구입니다.

• PITR = 연속 백업, 어느 초로든 복원 — 설정 가능한 윈도 1~35일 안에서 (예전에는 고정 35일이었습니다).
• 온디맨드 백업 = 수동 전체 스냅샷 — PITR의 윈도와 무관하게 원하는 만큼 보관합니다.
• 복원은 새 테이블을 만듭니다. 새 이름으로 복원한 다음 전환합니다 — 원본은 손대지 않습니다.
• PITR는 복원 지점 수가 아니라 테이블 크기로 과금됩니다 — DynamoDB 가격 계산기로 추정하세요.

문제: 제자리에서 되돌릴 수 없는 실수

DynamoDB에는 롤백할 수 있는 트랜잭션 로그가 없고 쓰기에 대한 "실행 취소"도 없습니다. 마이그레이션 스크립트가 모든 이벤트의 action 필드를 다시 쓰거나, 누군가 의도보다 넓은 삭제를 실행하면, 테이블은 그냥 잘못된 상태가 됩니다. 백업이 없으면 데이터는 사라집니다.

감사 로그 — 그 전체 가치가 믿을 수 있는 기록이 되는 것인 — 에게 "지난 화요일의 이벤트를 되찾을 수 없다"는 것은 단순한 불편이 아니라 규정 준수 실패입니다.

백업과 PITR가 작동하는 방식

특정 시점 복구는 일단 활성화되면 연속적 자동 백업을 찍습니다. AWS 문서에 따르면, PITR는 초 단위 복원 세분성으로 테이블 데이터의 완전 관리형 연속 백업을 제공합니다. 윈도는 RecoveryPeriodInDays를 통해 1~35일로 설정 가능하고, 그 안의 어느 초로든 — 실시간보다 대략 5분 뒤(LatestRestorableDateTime)까지 — 복원할 수 있으며, 다른 리전으로도 가능합니다.

한 가지 중요한 경계: 복구 기간을 줄이면 가장 이른 복원 지점이 즉시 줄어들고, PITR를 껐다가 다시 켜면 복구 가능 시작 시간이 리셋됩니다 — 이전의 연속 이력을 잃습니다.

PITR는 관리형 S3로 내보내기의 전제 조건이기도 합니다: 내보내기가 같은 연속 백업에서 읽기 때문에, PITR가 꺼져 있으면 ExportTableToPointInTime이 PointInTimeRecoveryUnavailableException으로 실패합니다.

온디맨드 백업은 별개입니다: 명시적으로 생성해 무기한 보관하는 수동 전체 테이블 스냅샷으로, 마이그레이션 전 체크포인트나 35일 PITR 윈도를 넘어서는 장기 규정 준수 아카이브에 유용합니다. 요청은 즉시 처리되고 백업은 몇 분 안에 복원 가능해지며, 테이블의 처리량은 전혀 소비하지 않고, 몇 개를 보관하든 개수 제한이 없습니다. 문서가 밝히는 솔직한 단서 하나: 온디맨드 백업은 항목 간 인과적 일관성을 보장하지 않습니다 — 갱신 사이의 편차는 "usually much less than a second"이지만, 쓰기가 몰아치는 도중에 찍은 백업은 단일한 정지 순간이 아닙니다.

복원이 되살려주지 않는 것

복원은 테이블의 데이터와 인덱스를 다시 만들 뿐, 그 운영 배선까지 되살리지는 않습니다. AWS 문서에 따르면, 복원된 테이블에서는 오토 스케일링 정책, IAM 정책, CloudWatch 지표와 경보, 태그, 스트림 설정, TTL, 삭제 방지, 그리고 PITR 자체를 직접 다시 구성해야 합니다. 백업에서 복원하고 PITR 재활성화를 잊는 것 — 그것이 다음 사고를 복구 불가능하게 만드는 방식입니다.

복원 시점에 의도적으로 바꿀 수 있는 설정도 있습니다 — 청구 모드, 프로비저닝된 용량, 암호화 키 — 그리고 보조 인덱스의 일부 또는 전부를 제외할 수 있는데, 나중에 다시 만들 수 있다면 복원이 더 빠르고 저렴해집니다. 복원은 다른 리전을 대상으로 할 수도 있고, 기존 테이블을 덮어쓰는 일은 절대 없습니다.

AWS Backup으로 예약 백업하기

DynamoDB 자체의 온디맨드 백업에는 스케줄러가 없습니다. 보존 정책을 갖춘 반복 백업이 필요하다면, DynamoDB는 AWS Backup과 기본 통합됩니다 (AWS 문서). 백업 계획은 수명 주기 규칙(콜드 스토리지 전환 포함)이 딸린 예약 백업, DR을 위한 자동 교차 계정 및 교차 리전 복사, 백업 볼트를 통한 독립적인 KMS 키, 그리고 아무도 조용히 지울 수 없는 WORM 규정 준수 태세를 위한 Vault Lock을 제공합니다. 운영상 함정 두 가지: AWS Backup은 계정별·리전별 명시적 옵트인이 필요하고, 그것이 만든 백업(유형 AWS_BACKUP)은 DynamoDB 콘솔에서 삭제할 수 없습니다 — AWS Backup에서 관리하세요.

둘 다 기존 테이블 위가 아니라 새 테이블로 복원합니다:

실전 예제: 잘못된 마이그레이션에서 복구하기

expiresAt 속성을 추가하려던 마이그레이션이 대신 모든 이벤트의 action을 빈 문자열로 덮어썼습니다. PITR가 35일 윈도로 켜져 있으므로, 마이그레이션이 실행된 _직전_의 초로 복원합니다:

복원을 검증하는 동안 손상된 테이블은 손대지 않습니다 — 복원된 이벤트를 라이브 이벤트와 비교하고, action 값이 돌아왔는지 확인한 다음, 앱을 다시 가리킵니다. 복구 자체에서는 아무것도 파괴되지 않습니다.

손실이 전체 테이블 손상이 아니라 소수의 항목이었다면, 대신 라이브 데이터와 복원된 사본을 점검해 영향받은 행만 옮길 수 있습니다 — DynamoDB 테이블 복사를 참고하세요.

DynoTable에서 해보기

복원은 그에 대한 검증만큼만 좋습니다. audit-log-restored로 복원한 뒤에는, 복구된 이벤트를 실제로 들여다보고 실수 전에 있었어야 할 모습과 일치하는지 확인해야 합니다.

DynoTable은 복원된 테이블에 다른 어떤 테이블과 마찬가지로 연결되므로, 영향받은 테넌트의 이벤트를 쿼리하고, action 값이 올바른지 확인하고, 전환하기 전에 라이브 테이블과 비교할 수 있습니다 — 복원을 믿음의 도약에서 검증된 복구로 바꿔줍니다.

복구된 이벤트를 오프라인 규정 준수 기록용으로 내보낼 수도 있습니다 — DynamoDB를 CSV로 내보내기를 참고하세요.

함정과 다음 단계

• 필요해지기 전에 PITR를 활성화하세요. 켜진 순간부터만 보호합니다 — 소급 복구는 없습니다. 데이터를 잃을 여유가 없는 테이블에는 켜두세요.
• PITR를 비활성화하면 윈도가 리셋됩니다. 껐다가 다시 켜면 연속 이력이 지워집니다. 복구 가능 시작 시간이 재활성화 시점부터 다시 시작합니다.
• 복원은 즉시도 아니고 공짜도 아닙니다. 복원은 완전히 새로운 테이블을 프로비저닝하고 크기에 비례해 시간이 걸립니다. 소요 시간과 추가 테이블을 예산에 넣으세요.
• 35일은 아카이브가 아닙니다. PITR 윈도를 넘어서는 보존에는 온디맨드 백업을 찍거나 S3로 내보내세요 — PITR는 복구 윈도이지 장기 스토리지가 아닙니다.

그것으로 감사 로그 운영 루프가 닫힙니다: 일관성을 위한 트랜잭션, 반응을 위한 Streams, 만료를 위한 TTL, 비용을 위한 올바른 용량 모드, 리전 복원력을 위한 글로벌 테이블, 그리고 데이터 복구를 위한 PITR. 이것들이 어떻게 맞물리는지는 운영 & 비용 개요를 다시 살펴보세요.

DynoTable을 다운로드해 복원된 테이블에 연결하고, 신뢰하기 전에 복구를 검증하세요.