데이터베이스 자동 백업, 보존 기간과 복구 시점

보존 기간이 돌아갈 수 있는 범위입니다

자동 백업의 보존 기간은 단순한 보관 설정이 아니라 '언제로 돌아갈 수 있는가'의 범위입니다. 보존 기간을 7일로 두면 과거 7일, 즉 168시간 안의 임의 시점으로 복구할 수 있습니다. 그 바깥으로는 돌아갈 수 없습니다. 그래서 기간을 정하는 기준은 비용이 아니라 데이터 문제를 며칠 뒤에 발견하는지입니다. 월말 집계에서 오류를 발견하는 업무가 있다면 7일로는 부족합니다. 또 보존 기간을 0으로 두면 자동 백업이 꺼지고 특정 시점 복구가 불가능해지므로, 시험 환경이라도 0으로 두기 전에 영향을 확인해야 합니다.

특정 시점 복구는 새 인스턴스를 만듭니다

특정 시점으로 복구할 때 기존 인스턴스가 그 시점으로 되돌아가는 것이 아니라, 그 시점 상태의 새 인스턴스가 만들어집니다. 이 차이가 복구 절차를 바꿉니다. 복구 뒤에는 애플리케이션이 바라보는 주소를 새 인스턴스로 바꾸는 작업이 필요합니다. 그래서 절차서에 세 단계를 적습니다. 1단계 복구할 시점 확정, 2단계 새 인스턴스 생성, 3단계 연결 주소 전환입니다. 3단계를 위해 애플리케이션이 주소를 설정으로 읽도록 만들어 두어야 합니다. 주소가 코드에 박혀 있으면 복구는 되는데 전환에 배포가 필요해 시간이 더 걸립니다.

복구 소요 시간을 계산합니다

학습용 가정으로 계산합니다. 가정값은 데이터 크기가 500기가바이트이고 복원 처리 속도가 분당 2기가바이트라고 두겠습니다. 복원 시간은 250분이고 시간으로는 약 4.17시간입니다. 이것이 중간 계산값입니다. 최종 복구 시간에는 시점 확정에 걸리는 시간과 연결 전환 시간이 더해집니다. 문제를 발견하고 어느 시점으로 돌아갈지 정하는 데 1시간이 걸리고 전환에 15분이 걸린다면 총 복구 시간은 5시간을 넘습니다. 이 값이 업무가 허용하는 복구 시간보다 길면, 자동 백업만으로는 부족하고 대기 복제본 같은 수단을 함께 둬야 합니다.

백업만으로 막지 못하는 상황

결론을 뒤집는 조건이 있습니다. 첫째, 인스턴스를 삭제할 때 자동 백업도 함께 사라질 수 있습니다. 삭제 전에 최종 스냅샷을 남기는 선택을 하지 않으면 복구 수단이 없어집니다. 그래서 삭제 절차에 최종 스냅샷 생성을 필수 항목으로 넣습니다. 둘째, 자동 백업은 같은 계정과 같은 리전에 보관되는 경우가 많습니다. 계정 수준 사고나 리전 장애에는 대응하지 못하므로, 중요한 데이터는 다른 위치로 사본을 내보내는 절차를 따로 둡니다. 셋째, 보존 기간 안이라도 백업 작업이 실패한 구간이 있으면 그 시점으로는 돌아갈 수 없으므로 실패 알림을 설정합니다.

서버 운영 실행 전 점검표

• 보존 기간을 데이터 문제 발견 지연보다 길게 정했다
• 복구가 새 인스턴스를 만든다는 점을 절차서에 반영했다
• 애플리케이션이 연결 주소를 설정으로 읽도록 만들었다
• 삭제 시 최종 스냅샷과 백업 실패 알림을 설정했다