DynamoDB 백업 및 특정 시점 복구

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

감사 로그에는 이것이 타협 불가능한 요소입니다. 감사 로그는 변경 불가능한 규정 준수 기록이며, 이벤트를 다시 쓰는 잘못된 마이그레이션이나 실수로 인한 대량 삭제는 실수 직전 시점으로 복구할 수 있어야 합니다.

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

DynamoDB는 두 가지 백업 방식을 제공합니다. 특정 시점 복구(PITR)는 연속적이고 자동적인 백업을 수행하여, 구성 가능한 1~35일 윈도우 내 어느 초로든 복원할 수 있게 해줍니다. 온디맨드 백업은 무기한 보관하는 수동 전체 스냅샷입니다. 둘 다 원본을 덮어쓰지 않고 새 테이블로 복원되므로, 제자리에서 되돌리는 실행 취소가 아니라 복구 도구입니다.

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

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

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

신뢰할 수 있는 기록이라는 점이 전부인 감사 로그에서 "지난 화요일 이벤트를 되살릴 수 없다"는 것은 단순한 불편이 아니라 규정 준수 실패입니다.

백업과 PITR의 작동 방식

특정 시점 복구는 활성화되면 연속적인 자동 백업을 수행합니다. AWS 문서에 따르면 PITR는 "초 단위 세분성으로 최대 35일의 복구 지점을 갖춘, 완전 관리형 자동 연속 백업을 테이블 데이터에 제공합니다." 윈도우는 RecoveryPeriodInDays를 통해 1일에서 35일까지 구성 가능하며, 다른 리전을 포함해 윈도우 내 어느 초로든 복원할 수 있습니다.

한 가지 중요한 점: 복구 기간을 줄이면 가장 이른 복원 지점이 즉시 줄어들고, PITR를 비활성화한 뒤 다시 활성화하면 복구 가능 시작 시점이 초기화됩니다 — 이전의 연속 기록을 잃게 됩니다.

온디맨드 백업은 별개입니다. 명시적으로 직접 생성하여 무기한 보관하는 수동 전체 테이블 스냅샷으로, 마이그레이션 전 체크포인트나 35일 PITR 윈도우를 넘어서는 장기 규정 준수 아카이브에 유용합니다.

둘 다 기존 테이블 위에 덮어쓰는 것이 아니라 새 테이블로 복원합니다:

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

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

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

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

DynoTable에서 해보기

복원은 검증한 만큼만 신뢰할 수 있습니다. audit-log-restored로 복원한 뒤에는, 복구된 이벤트를 실제로 살펴보고 실수 전에 있어야 했던 모습과 일치하는지 확인해야 합니다.

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

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

함정과 다음 단계

• 필요해지기 전에 PITR를 활성화하세요. 켜진 순간부터만 보호하며 — 소급 복구는 없습니다. 잃어선 안 되는 데이터가 있는 테이블이라면 켜두세요.
• PITR를 비활성화하면 윈도우가 초기화됩니다. 껐다 켜면 연속 기록이 지워지고, 복구 가능 시작 시점이 다시 활성화 시점부터 시작됩니다.
• 복원은 즉각적이지도 무료도 아닙니다. 복원은 완전히 새로운 테이블을 프로비저닝하며 크기에 비례하는 시간이 걸립니다. 그 소요 시간과 추가 테이블을 감안하세요.
• 35일은 아카이브가 아닙니다. PITR 윈도우를 넘어서는 보존이 필요하면 온디맨드 백업을 받거나 S3로 내보내세요 — PITR는 복구 윈도우이지 장기 저장소가 아닙니다.

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

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