'백업 잘 되고 있죠?'라고 물으면 대부분 '네, 매일 돌고 있습니다'라는 답이 돌아옵니다. 실제로 백업 작업이 성공했다는 기록도 남아 있습니다. 그런데 '어제 오후 3시에 지워진 주문 데이터를 오늘 되살릴 수 있나요?'라고 다시 물으면 답이 잘 나오지 않습니다.
이 둘은 완전히 다른 질문입니다. 백업은 파일이 만들어졌다는 사실이고, 복구는 서비스가 원래대로 돌아왔다는 결과입니다. 그 사이에는 보관 기간, 되돌릴 수 있는 시점의 간격, 복구에 걸리는 시간, 추가로 나가는 비용이 끼어 있습니다.
복구가 된다고 말하려면 숫자 네 개를 댈 수 있어야 합니다
첫째는 며칠 전까지 되돌릴 수 있는지입니다. 둘째는 그 안에서 몇 분 단위의 시점을 고를 수 있는지입니다. 셋째는 복구를 끝내는 데 몇 시간이 걸리는지이고, 넷째는 그동안 요금이 얼마나 더 나가는지입니다.
네 숫자 중 하나라도 비어 있으면 아직 복구가 된다고 말할 수 없는 상태입니다. 실무에서는 사고가 난 뒤에야 이 숫자를 처음 재보게 되고, 그때는 이미 선택지가 없습니다.
백업은 작업의 이름이고, 복구는 결과의 이름입니다. 작업이 도는 것을 확인했다고 결과를 확인한 것은 아닙니다.
AWS RDS 기본 보관 기간은 7일이고, 명령줄로 만들면 1일입니다
AWS 공식 문서 기준으로 RDS 인스턴스를 콘솔에서 만들면 자동 백업 보관 기간의 기본값이 7일입니다. 그런데 같은 인스턴스를 CLI나 API로 만들면서 값을 지정하지 않으면 기본값이 1일이 됩니다. 인프라를 코드로 관리하는 팀에서 이 차이를 모르고 넘어가는 경우가 많습니다.
설정할 수 있는 범위는 0일에서 35일이고, 0으로 두면 자동 백업 자체가 꺼집니다. 그리고 이 값을 0에서 0이 아닌 값으로, 또는 그 반대로 바꾸면 데이터베이스에 중단이 발생합니다. 보관 기간을 늘리는 작업도 서비스 시간을 피해서 잡아야 합니다.
되돌릴 수 있는 시점은 5분 뒤부터 시작합니다
RDS는 트랜잭션 로그를 5분마다 S3로 올립니다. 그래서 되돌릴 수 있는 가장 최근 시점은 보통 지금으로부터 5분 전이고, 사고가 방금 났다면 마지막 몇 분치는 되찾지 못합니다.
대신 보관 기간 안이라면 초 단위로 시점을 지정할 수 있습니다. 어제 오후 3시 12분 30초처럼 사고 직전으로 끊을 수 있다는 뜻입니다. 이 점이 하루 한 번 스냅샷을 뜨는 방식과 갈리는 지점입니다.
복원은 원본을 되돌리는 것이 아니라 새 서버를 만드는 일입니다
RDS의 시점 복원은 원본 인스턴스를 그대로 두고 새 인스턴스를 하나 더 만듭니다. 접속 주소가 새로 생기기 때문에, 복원이 끝나도 애플리케이션 설정을 바꿔 끼우기 전까지는 서비스가 돌아오지 않습니다.
새 인스턴스는 사용 가능 상태가 된 뒤에도 백그라운드로 데이터를 읽어오는 동안 평소 성능이 나오지 않습니다. 또 복원할 때 저장 용량은 줄일 수 없고, 늘리려면 최소 10퍼센트 이상이어야 합니다. 원본과 같은 사양으로 복원하는 편이 안전합니다.
국내 호스팅은 하루 1회, 7일치가 사실상 기준선입니다
카페24 안내 문서를 보면 뉴매니지드 워드프레스는 매일 자동 생성된 백업본 최근 7일치로 복원할 수 있습니다. 반대로 서버호스팅은 자동 백업 기능이 없고 사용자가 직접 관리해야 한다고 명시돼 있습니다.
가비아 웹에이전시호스팅은 최근 7일간의 웹과 DB 데이터를 자동 백업하고, 원하는 시점으로 실시간 복원할 수 있다고 안내합니다. 즉 하루 한 번 스냅샷 구조에서는 어제 오후 3시 사고가 나면 어제 새벽 백업으로 돌아가고, 그날 낮에 들어온 주문은 전부 사라집니다.
복구에 걸리는 시간은 어디에도 공개돼 있지 않습니다
보관 기간은 공개돼 있지만, 복원 요청을 넣고 몇 시간 만에 끝나는지는 공개된 문서에서 확인되지 않습니다. 카페24와 가비아의 안내 문서에도 복원 소요 시간과 별도 비용은 나와 있지 않습니다.
복원을 1:1 문의로 접수하는 구조라면 사고 시각이 새벽인지 영업시간인지에 따라 복구 시간이 몇 시간씩 달라집니다. 이 숫자는 아무도 대신 알려주지 않으므로, 직접 한 번 재보는 것 말고는 알 방법이 없습니다.
비용은 백업 보관보다 복원 뒤에 더 나옵니다
AWS는 리전 안에서 프로비저닝한 저장 용량 총량만큼 백업 저장 공간을 무료로 제공하고, 그것을 넘는 분량만 과금합니다. 보관 기간을 7일에서 35일로 늘리면 이 초과분이 늘어납니다.
더 큰 비용은 복원 쪽입니다. 시점 복원은 인스턴스를 새로 만드는 일이라, 원본을 아직 지우지 않았다면 그 기간 동안 데이터베이스 요금이 두 배로 나갑니다. 검증에 하루가 걸리면 하루치가 그대로 붙습니다.
삭제 사고는 대부분 보관 기간이 지난 뒤에 발견됩니다
잘못된 조건으로 실행한 삭제 명령은 백업에도 그대로 반영됩니다. 지워진 상태가 성실하게 백업되는 것이고, 7일이 지나면 지워지기 전 상태는 어디에도 남지 않습니다. 회원 탈퇴 처리나 배치 정리 작업의 오류는 몇 주 뒤 정산할 때 드러나는 일이 흔합니다.
인스턴스를 삭제할 때도 함정이 있습니다. AWS 문서에 따르면 삭제 시 자동 백업 보존을 선택하지 않으면 자동 백업도 함께 사라집니다. 반면 수동 스냅샷은 인스턴스를 지워도 남고 리전당 100개까지 보관할 수 있으니, 분기 마감이나 대형 배포 직전에는 수동 스냅샷을 따로 남기는 편이 낫습니다.
분기마다 이 여섯 가지를 실제로 해보세요
읽고 확인하는 점검은 의미가 없습니다. 실제로 복원을 실행해야 숫자가 나옵니다. 분기에 한 번, 반나절이면 끝나는 절차로 만드는 것을 권합니다.
- 어제 날짜의 임의 시각을 하나 정하고, 그 시점으로 복원을 실제로 실행합니다.
- 복원 시작부터 접속 가능 상태까지 걸린 시간을 분 단위로 기록합니다.
- 복원본에서 주문이나 회원 데이터 한 건을 직접 조회해 내용이 맞는지 확인합니다.
- 애플리케이션 접속 설정을 복원본으로 바꾸는 데 걸린 시간을 따로 잽니다.
- 담당자 한 명이 없다고 가정하고, 다른 사람이 문서만 보고 같은 절차를 밟게 합니다.
- 이미지와 첨부 파일도 같은 시점으로 맞출 수 있는지 확인합니다.
이 여섯 개를 마치면 '어제 데이터를 몇 시간 만에, 어느 시점으로 되돌릴 수 있는가'에 숫자로 답할 수 있습니다. 그 숫자가 감당할 수 없는 크기라면 보관 기간을 늘리거나 백업 주기를 바꿀 근거가 생깁니다.
이 점검이 필요 없거나 맞지 않는 경우도 있습니다
데이터가 하루에 몇 건 늘지 않는 소개형 홈페이지라면 분기 점검은 과합니다. 이런 경우에는 1년에 한 번 복원해 보는 정도로 충분하고, 대신 파일과 DB를 각각 어디서 받을 수 있는지만 문서로 남겨두시면 됩니다.
주의할 점도 있습니다. SQL Server를 쓰면 여러 데이터베이스에 걸친 트랜잭션이 서로 다르게 복원될 수 있다고 AWS가 명시하고 있으므로, 이 구조에서는 복원 뒤 정합성 확인이 필수입니다. 또 자동 백업이 원본과 같은 계정 안에 있으면 계정 자체가 뚫렸을 때 함께 사라지므로, 그 위험까지 막으려면 별도 보관처가 필요합니다.
운영 중에 겪은 다른 사례는 운영 노트와 실무 가이드에 정리해 두었습니다. AWS의 시점 복원 동작은 공식 문서에서 확인할 수 있고, 서비스 구조에 맞는 백업 설계가 필요하시면 Codeforest로 문의하세요.
결론: 백업 성공 로그 대신 복구 시간을 숫자로 가지세요
기본값은 대부분 7일이고, 명령줄로 만든 RDS는 1일일 수도 있습니다. 되돌릴 수 있는 시점은 RDS라면 초 단위지만, 하루 1회 스냅샷이라면 하루 단위입니다. 이 차이가 사고 당일의 매출을 살리느냐 버리느냐를 가릅니다.
복구에 걸리는 시간은 어느 업체도 공개하지 않으니 직접 재는 수밖에 없습니다. 분기에 한 번 실제로 복원해 보고, 걸린 시간과 되돌린 시점을 기록해 두세요. 그 기록이 있어야 비로소 복구가 됩니다라고 말할 수 있습니다.
