백업이 켜져 있다는 말은 복구 계획이 있다는 말과 다르다. RDS의 자동 백업과 수동 스냅샷은 생성·보존·사용 목적이 다르므로, 데이터 변경 전과 장애 대응에서 각각 어떤 복구 지점을 쓸지 정해야 한다.
자동 백업은 운영 복구 창을 위한 기능이다
자동 백업 보존 기간과 백업 창은 서비스의 복구 요구사항에 맞춰 정한다. 특정 시점으로 되돌려야 하는 사고가 있다면 얼마나 과거까지, 얼마나 빠르게 복구해야 하는지가 먼저다. 백업 과정이 서비스 부하·유지보수 창과 충돌하지 않는지도 확인한다.
예를 들어 오전 10시에 잘못된 데이터 변경을 발견했다면 '어제 스냅샷이 있다'만으로 충분하지 않을 수 있다. 필요한 복구 시점이 오전 9시 55분인지, 전날 밤인지 먼저 정하고 자동 백업의 복구 가능 범위를 확인한다. 새 복원 인스턴스에서 필요한 데이터가 돌아왔는지 검증하기 전에는 원래 DB를 변경하지 않는 편이 안전하다.
수동 스냅샷은 변경 전 기준점으로 쓸 수 있다
스키마 변경이나 큰 데이터 작업 전에는 목적과 보존 책임이 분명한 스냅샷이 도움이 된다. 하지만 스냅샷 생성 후 원래 인스턴스를 덮어쓴다고 가정하면 위험하다. 복구는 보통 새 인스턴스나 새 엔드포인트로 이어질 수 있으므로, 애플리케이션 연결 전환·검증·되돌리기 절차까지 계획해야 한다.
복구 테스트에서는 새 엔드포인트에 읽기 전용으로 연결해 핵심 테이블의 행 수와 샘플 데이터를 확인하고, 애플리케이션 전환 전후의 연결 설정을 별도로 점검하자. 복원 시간이 요구한 복구 시간 안에 들어오는지도 기록해야 백업 정책을 실제로 평가할 수 있다.
백업이 있다는 말과 복원할 수 있다는 말은 다르다
테스트용 데이터베이스의 특정 행을 기준으로 복구 절차를 적어 보자. 변경 전 수동 스냅샷을 만들고, 별도 DB 인스턴스로 복원한 다음 아래처럼 기준 행을 조회한다. 예시의 테이블·ID는 실제 데이터베이스에 맞게 바꾼다.
SELECT id, status FROM orders WHERE id = 42;원본 인스턴스의 행과 복원된 인스턴스의 행을 비교하면 스냅샷 시점과 검증 대상을 분명히 할 수 있다. 자동 백업의 시점 복구는 설정된 보존 기간을 확인해야 하고, 스냅샷 복원은 원본을 제자리에서 되감는 동작이 아니라 새 인스턴스를 만든다. 연결 문자열 전환까지 해 봐야 복구 계획이 완성된다.
핵심 요약
자동 백업은 운영 복구 창, 수동 스냅샷은 의도적인 기준점에 적합하다. 둘 다 존재 여부만 보지 말고 복구 시간·연결 전환·데이터 검증까지 연습하자. 백업은 복원해 확인하기 전까지는 가정일 뿐이다.
작성자
기초 개념을 구현과 검증, 실제 운영 판단까지 연결해 기록합니다.
