RDS 시점 복구 연습: 새 DB 검증부터 접속 전환·롤백까지
AI Editter
RDS에서 원하는 시각을 선택해 복원을 시작했다고 애플리케이션까지 복구된 것은 아닙니다. 시점 복구는 새 DB 인스턴스를 만들며, 새 엔드포인트와 네트워크·파라미터·인증 조건을 검증해야 합니다.
AWS의 RDS 시점 복구 문서는 원본을 수정하지 않고 새 DB 인스턴스를 만드는 동작과 복원 범위를 설명합니다. 이 글은 RDS DB 인스턴스 기준이며 Aurora의 클러스터 복원은 해당 서비스 절차를 별도로 확인합니다.
복구하려는 시각을 먼저 확정
① 복구할 원본 DB의 자동 백업을 선택합니다. ② Earliest·Latest restorable time 사이에 원하는 복구 시점이 있는지 확인합니다. ③ Actions에서 시점 복원 메뉴로 이동합니다. 선택 전에는 버튼이 비활성일 수 있습니다. 이어지는 화면에서 시간대·새 DB 식별자·네트워크를 확인합니다.
잘못된 배치가 14:10에 실행됐다면 단순히 “14:10 직전”을 선택하기 전에 시간대와 실제 커밋 시각을 확인합니다. 애플리케이션 로그, DB 감사 기록, 배치 실행 기록의 시간대가 다를 수 있습니다.
복구 시각 이후의 정상 거래도 되돌아간다는 점을 고려합니다. 장애 데이터만 제거할지, 전체 DB를 과거로 돌릴지, 복원한 DB에서 필요한 행을 추출할지 결정해야 합니다. 시점 복구가 잘못된 변경 한 건만 취소하는 기능은 아닙니다.
| 기록 | 확인할 값 |
|---|---|
| 오류 시작 | 실제 변경·커밋 시각과 시간대 |
| 복원 가능 범위 | earliest/latest restorable time |
| 선택 시점 | UTC와 업무 시간대 모두 기록 |
| 이후 정상 거래 | 복구 또는 재처리 대상 |
| 업무 허용 손실 | 사전에 정한 범위 |
새 DB의 설정을 비교할 목록
인스턴스 클래스와 스토리지뿐 아니라 VPC, 서브넷, 보안 그룹, 파라미터 그룹, 옵션 그룹, 암호화 키, 백업·모니터링 설정을 확인합니다. 복원 화면의 기본 선택을 기존 운영값과 같다고 가정하지 않습니다.
복원 연습은 운영 앱이 자동으로 연결하지 않는 별도 이름과 제한된 네트워크에서 진행합니다. 외부 메일·결제·동기화 같은 부작용이 있는 작업은 시험 환경에서 비활성화하거나 시험 대상으로 제한합니다.
새 DB가 available이 된 시각과 실제 조회 성능이 안정된 시각을 구분합니다. 데이터 로딩과 캐시, 앱 연결 준비에 따라 업무 복구 시간이 더 길어질 수 있습니다.
데이터는 건수와 업무 기준으로 검산
가상의 주문 DB라면 다음 항목을 확인합니다.
| 검사 | 기대 결과 |
|---|---|
| 복구 시점 이전 정상 주문 | 존재 |
| 잘못된 배치가 만든 변경 | 선택 시점 기준으로 제외 |
| 주문·상세·결제 관계 | 연결 누락 없음 |
| 기간별 건수·금액 | 보관한 통제값과 일치 |
| 최근 정상 거래 | 예상 시점까지 반영 |
| 앱 계정 권한 | 필요한 읽기·쓰기 가능 |
복원 시점이 다르면 현재 운영 DB와 전체 건수가 같을 필요는 없습니다. 시점에 맞는 기준값으로 비교합니다. 단순히 테이블이 존재하거나 로그인에 성공한 것만으로 복구 판정을 내리지 않습니다.
읽기 전용 검사를 먼저 하고, 쓰기 시험은 격리된 테스트 거래로 수행합니다. 시퀀스·트리거·확장 기능·시간대 설정처럼 새 입력에 영향을 주는 요소도 확인합니다.
접속 전환 전에 쓰기 주체를 하나로 정한다
새 DB 검증이 끝나면 애플리케이션의 실제 연결 설정과 연결 풀을 확인합니다. 비밀 저장소나 배포 설정에서 엔드포인트를 바꾸는 방식이라면 어떤 앱과 배치가 이를 참조하는지 목록이 필요합니다.
전환 시간에는 필요한 쓰기 중지와 연결 종료 절차를 수행하고, 구 DB에 쓰는 프로세스가 남아 있지 않은지 확인합니다. 웹 서버만 바꾸고 워커나 정산 배치를 놓치면 두 DB에 데이터가 갈라질 수 있습니다.
DNS 별칭을 사용하더라도 TLS 호스트명 검증과 클라이언트 동작을 확인합니다. 별칭 하나를 바꾸는 것으로 모든 기존 연결이 즉시 전환된다고 가정하지 않습니다.
되돌리기는 새 DB에 쓰기 전후가 다르다
새 DB에 아직 업무 쓰기가 없다면 기존 연결 설정으로 되돌리는 계획이 비교적 단순합니다. 새 DB에 주문이 쌓인 뒤에는 구 DB로 주소만 바꾸면 새 거래가 사라져 보일 수 있습니다.
롤백 기준에는 성능·오류율뿐 아니라 전환 이후 데이터 처리 방법을 포함합니다. 새 거래를 재처리할지, 양쪽 변경을 대조할지, 재전환을 중단할지 사전에 정합니다. DB 복구에서는 “원복 가능”이라는 말에 데이터 시점이 빠지면 안 됩니다.
연습 결과로 복구 시간을 다시 계산
복원 시작, DB 준비, 데이터 검증 완료, 앱 연결, 업무 확인 완료 시각을 각각 기록합니다. 이 합계가 실제 복구 목표 시간과 맞는지 봅니다. 실패한 검사는 원인과 수정 내용을 남기고 관련 구간을 다시 시험합니다.
연습 후에는 시험 DB·스냅샷·로그 등 생성한 자원을 목록과 대조해 정리합니다. 복원 리소스는 운영과 별개로 과금될 수 있습니다. 최종 산출물은 성공 화면 한 장보다 다음 담당자가 같은 순서로 수행할 수 있는 복구 기록과 검증표가 되어야 합니다.