백업과 복구, 되돌린 자리는 원래 자리가 아니다

집에 불이 났을 때 보험이 하는 일은 불이 나기 전으로 되돌리는 것이 아니에요. 같은 값어치의 집을 새로 마련해 주는 것이에요. 주소가 달라지고, 가구 배치를 다시 해야 하고, 이사한 사실을 아는 사람들에게 알려야 해요. 복구됐다는 말과 원래대로 돌아갔다는 말은 달라요.

AWS는 자동 백업을 켜 두면 정해진 보관 기간 동안 특정 시점으로 되돌릴 수 있게 해 둬요. 데이터베이스 복구가 정확히 이래요. 백업이 있다는 사실은 확인하기 쉬운데, 복구한 뒤에 무엇이 달라져 있는지는 실제로 해 보기 전까지 잘 몰라요.

제자리로 돌아가지 않는다

AWS 문서의 첫 문장이 이 성격을 그대로 말해요. 특정 시점으로 복구하면 원본을 건드리지 않은 채 새 인스턴스가 만들어진다는 것이에요.

그래서 복구는 한 단계로 끝나지 않아요. 새 자리가 생기고, 애플리케이션이 보던 연결 주소를 그쪽으로 옮겨야 하고, 옮기는 동안에는 어느 쪽이 진짜인지 정해 두어야 해요. 앞 글에서 장애 조치를 다루며 전환 자체보다 전환을 아는 일이 어렵다고 적었는데, 복구는 전환을 사람이 직접 해야 한다는 점에서 한 겹 더 무거워요.

기록을 지우기 전 시점으로 새 DB를 만들고 앱의 연결을 확인해 보세요.

원래 DB

기록 없음

앱이 여기를 읽음

복원 DB

아직 없음

RDS 시점 복구는 원래 DB 옆에 새 DB를 만들어요. 앱이 그 DB를 읽으려면 연결도 전환해야 해요.

앱은 기록이 지워진 원래 DB를 읽고 있어요.

새 DB에 과거 기록이 돌아왔어요. 앱의 연결은 원래 DB에 그대로 남아 있어요.

연결을 전환한 뒤에야 앱이 복원한 기록을 읽어요. 원래 DB는 바뀌지 않았어요.

복원 시점 뒤의 쓰기는 새 DB에 포함하지 않는 예시예요. 설정·성능 회복과 실제 전환 준비는 별도로 확인해야 해요.

돌아오지 않는 것들

같은 문서에 실제로 겪기 전에는 잘 모르는 조건이 둘 더 있어요.

하나는 설정이에요. 복구된 인스턴스는 기본 파라미터 그룹과 옵션 그룹에 자동으로 연결돼요. 그동안 조정해 둔 값들이 붙어 오지 않는다는 뜻이에요. 콘솔로 복구하면 끝난 뒤에 다시 지정해야 하고, 명령으로 복구하면 요청할 때 지정할 수 있어요. 급한 상황에서 데이터만 확인하고 넘어가면, 다른 설정으로 돌고 있는 것을 한참 뒤에 알게 돼요.

다른 하나는 성능이에요. 문서는 복구가 끝나 인스턴스가 사용 가능해진 뒤에도 볼륨이 배경에서 계속 데이터 블록을 읽어 올리며, 그동안 완전히 동작하기는 하지만 초기화가 끝날 때까지 성능이 제 상태가 아닐 수 있다고 적어요. 그래서 복구 직후의 응답 속도로 판단하면 실제보다 나쁘게 보여요.

복구 중인 상태를 밖에서 확인할 방법도 있어요. 문서는 인스턴스 상태와 저장소 초기화 진행률을 조회할 수 있는 항목을 안내해요. 아직 채워지는 중인지 다 됐는지를 짐작이 아니라 값으로 볼 수 있어요.

여기에 시간 축도 하나 있어요. 문서는 트랜잭션 로그가 5분마다 저장소로 올라간다고 적고, 복구 가능한 가장 최근 시각을 따로 확인할 수 있게 해 두었어요. 되돌릴 수 있는 지점이 지금 이 순간이 아니라는 뜻이에요.

무엇이 돌아오나	상태	해야 할 일
데이터	지정한 시점까지	가장 최근 몇 분은 없을 수 있다
설정 묶음	기본값으로	조정해 둔 값을 다시 지정한다
성능	아직 오르는 중	초기화가 끝날 때까지 기다린다
연결 주소	새 자리	애플리케이션이 볼 곳을 옮긴다

네 줄 모두 데이터를 되찾은 다음에 남는 일이에요. 백업이 있느냐는 첫 번째 질문이고, 실제로 답이 필요한 질문은 이 과정에 얼마나 걸리느냐예요.

해 본 적 있느냐가 갈린다

AWS도 백업과 복구를 장애 대비의 한 축으로 묶어 설명해요. 복구 절차는 문서를 읽으면 어렵지 않아요. 그런데 한 번도 해 보지 않은 절차는 급할 때 처음 해 보는 절차가 돼요. 그 시점에는 설정이 기본값으로 돌아간다는 것도, 성능이 아직 안 오른다는 것도 모른 채 화면을 보게 돼요.

앞 시리즈에서 폴백 경로를 이야기하며 대비책이 하는 일은 사고를 막는 것만이 아니라 평소에 손댈 용기를 주는 것이라고 적었어요. 복구도 같아요. 한 번 해 보면 걸리는 시간을 알게 되고, 알고 나면 그 시간을 전제로 다른 결정을 세울 수 있어요.

저는 무엇을 재 보지 않았나

제가 만드는 앱에서 백업은 켜 두었어요. 오래 그 상태로 두었고, 켜져 있다는 사실을 확인한 것으로 준비가 됐다고 여겼어요.

앞 글을 쓰면서 실제로 한 번 복구해 봤어요. 데이터는 돌아왔지만 기다리는 시간이 있었고, 제가 쓰던 설정도 다시 살펴야 했어요. 사고가 난 날 처음 만났다면 데이터가 잘못된 것인지 설정이 달라진 것인지 구별하는 데 더 오래 걸렸을 것 같아요.

백업의 값어치는 얼마나 자주 뜨느냐가 아니라 얼마나 빨리 쓸 수 있느냐로 정해졌어요. 그리고 그 속도는 재 보기 전에는 알 수 없는 종류의 숫자였어요.