백업이 있어도 복구가 안 되는 이유 | 복구 리허설 체크 6가지

“백업은 매일 돌고 있어요”라는 말을 들으면 안심이 되죠. 그런데 실제로 장애가 터졌을 때, 그 백업으로 서비스를 되살리는 데 몇 시간이 걸릴지 재본 적이 있나요. 백업을 받는 것과 그걸로 복구가 되는 것은 생각보다 다른 이야기예요. 저희도 자체 서비스를 운영하면서 “파일은 있는데 복구가 막히는” 상황을 겪어봤어요. 오늘은 백업이 있어도 복구가 안 되는 이유와, 복구 리허설에서 미리 재봐야 할 것들을 정리해볼게요.

1. 백업은 됐는데 왜 복구가 안 될까요

백업과 복구를 한 묶음으로 생각하기 쉬운데, 둘은 다른 작업이에요. 백업은 데이터를 어딘가에 옮겨두는 일이고, 복구는 그 데이터로 서비스를 다시 돌아가게 만드는 일이에요. 앞은 자동으로 잘 도는데 뒤는 한 번도 안 해본 경우가 흔해요.

한 엔지니어링 현장의 경험을 보면, 재해 복구를 처음 실제로 테스트해보면 거의 매번 눈에 띄는 구멍이 드러난다고 해요. 설정 파일 하나가 백업에서 빠져 있거나, 복구 순서를 아무도 몰라 우왕좌왕하거나, 받아둔 백업이 열리지 않거나요. 평소엔 전혀 안 보이다가 정작 급할 때 터지는 게 이 구멍이에요.

2. RTO와 RPO — 두 개를 따로 봐야 해요

복구를 이야기할 때 꼭 나오는 두 단어가 있어요. RTO는 장애가 난 뒤 서비스가 다시 돌아가기까지 허용할 수 있는 최대 시간이에요. RPO는 “데이터를 어디까지 잃어도 되는가”, 즉 허용 가능한 최대 데이터 손실 시간이고요. 둘은 따로 정해야 해요.

RPO는 백업을 얼마나 자주 받느냐가 결정하고, RTO는 복구 역량이 결정해요. 하루에 한 번만 백업하면 최악의 경우 하루치 데이터가 날아갈 수 있어요(RPO). 또 백업은 있어도 복구 절차가 복잡해 실제로 6시간이 걸린다면, 그 서비스의 RTO는 사실상 6시간인 거예요. 이 두 숫자를 먼저 정해야 “지금 우리 백업이 충분한가”를 판단할 수 있어요.

3. 복구가 막히는 흔한 이유

복구가 실패하는 이유는 대개 몇 갈래로 나뉘어요. 가장 흔한 건 복구에 걸리는 시간을 아예 계획에 안 넣은 경우예요. 테스트 복구가 RTO보다 오래 걸리면, 실제 상황에서도 그만큼 걸린다고 봐야 하는데 이걸 재본 적이 없는 거죠.

절차가 너무 복잡한 것도 문제예요. 로그를 다 보관해도 복구 단계가 열몇 개로 얽혀 있으면 실제 복구가 늘어져요. 위기 상황에서 사람이 설정을 잘못 건드리거나 한 단계를 빠뜨리는 실수도 다운타임을 길게 만들고요. 그리고 가장 놓치기 쉬운 게 뒤에서 따로 다룰 “오염된 백업”이에요. 이유가 무엇이든 공통점은 하나예요. 미리 안 해봐서 몰랐다는 거죠.

4. 복구 리허설에서 실제로 재보는 6가지

복구 리허설은 백업이 아니라 “복구”를 진짜로 해보는 연습이에요. 받아둔 백업으로 서비스를 처음부터 되살려보면서, 아래 여섯 가지를 재고 기록해요.

확인 항목	무엇을 보나요
전체 복구 시간	감지 → 소통 → 복구 → 검증까지 걸린 시간을 재서 RTO와 비교
데이터 손실 범위	되살린 데이터가 RPO 안에 들어오는지
빠진 구성요소	설정·인증서·외부 연동처럼 백업에서 누락되기 쉬운 것
절차의 명확성	담당자가 문서만 보고 순서대로 복구할 수 있는지
사람 손이 필요한 지점	자동이 끊기고 수동 개입이 필요한 단계가 어디인지
복구본 검증	되살린 서비스가 실제로 정상 동작하는지(단순 “켜짐”이 아니라)

용어 한 줄 정리 — RTO(복구 목표 시간): 장애 후 서비스를 다시 돌리기까지 허용하는 최대 시간이에요. RPO(복구 시점 목표): 데이터를 어디까지 잃어도 되는지, 허용 가능한 최대 손실 시간이에요. 장애 조치(failover): 주 시스템이 죽으면 예비 시스템으로 자동 전환하는 걸 말해요. 실무에선 이 세 가지를 숫자와 절차로 적어두고 정기적으로 테스트해요.

AWS의 운영 지침에서도 복구 사이트로의 전환을 정기적으로 테스트해 RTO와 RPO가 지켜지는지 확인하라고 권해요. 그러면서 “실제 운영 환경에서만 전환을 테스트하는 것”은 피해야 할 방식으로 꼽아요. 터지고 나서 처음 해보는 복구는 리허설이 아니라 실전이니까요.

5. 오염된 백업 — 가장 최근 백업이 안전하지 않을 수 있어요

복구에서 가장 까다로운 상황이 보안 사고예요. 공격을 당했을 때 “가장 최근 백업으로 되돌리면 되지 않나” 싶지만, 그 최근 백업이 이미 감염된 상태일 수 있거든요. 겉보기엔 멀쩡한 오전 6시 백업이, 알고 보면 새벽 3시에 시작된 침해 이후의 데이터일 수 있어요.

이런 경우 실제로 안전한 복구 지점은 백업 시점보다 훨씬 앞으로 가야 해요. 그래서 백업은 한 시점만 두면 안 되고, 여러 시점을 일정 기간 보관해 “깨끗한 지점”을 고를 수 있게 해둬야 해요. 복구를 설계할 때 “언제 것으로 되돌릴 수 있나”를 함께 정해두는 이유예요.

6. 복구 범위를 어디까지 둘까요

복구를 준비할 때 “모든 걸 다 되살려야 한다”고 생각하기 쉽지만, 데이터마다 중요도가 달라요. 결제·주문 기록처럼 잃으면 안 되는 데이터와, 언제든 다시 만들 수 있는 임시 데이터를 똑같은 수준으로 보관하면 비용만 커져요.

그래서 복구 범위를 “무엇을, 얼마나 자주, 얼마나 오래 보관할지”로 나눠 정하는 게 좋아요. 핵심 데이터는 자주 백업하고 여러 시점을 길게 두고, 덜 중요한 데이터는 주기를 늘려요. 이렇게 나누면 복구 목표(RTO·RPO)는 지키면서 비용은 눌러요. 처음부터 범위를 정해두면, 나중에 “이것도 백업됐어야 했는데” 하고 당황하는 일이 줄어요.

7. 운영해본 개발사는 복구를 어떻게 준비할까요

직접 서비스를 운영해보면 “백업을 켜뒀다”에서 멈추지 않게 돼요. 장애는 언젠가 난다는 걸 전제로, 그때 몇 분 안에 되살릴 수 있는지를 미리 재보게 되거든요. 저희도 자체 SaaS 4종을 운영하면서, 복구는 사고가 난 뒤가 아니라 평소에 연습으로 손에 익혀두는 일이라는 걸 배웠어요.

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 그래서 새 서비스를 만들 때도 백업 설정만이 아니라 복구 절차와 리허설까지 함께 설계해요. 지금 운영 중인 서비스의 복구가 실제로 되는지 점검해보고 싶다면 복구 절차부터 같이 짚어드릴게요 →. 백업·복구의 기준을 어떻게 잡을지는 백업·복구 기준 정하는 법에, 복구 범위와 비용의 관계는 백업·복구 범위와 비용에서 이어서 보실 수 있어요.

자주 묻는 질문

복구 리허설은 얼마나 자주 해야 하나요?

서비스 규모와 변경 빈도에 따라 달라요. 구성이 자주 바뀌는 서비스라면 분기에 한 번은 재보는 게 안전하고, 큰 변경이 있었던 직후에도 한 번 확인하는 게 좋아요. 중요한 건 주기보다 “실제로 한 번은 해본다”예요.

백업 비용을 줄이려면 어디를 조정해야 하나요?

보관 주기와 보관 기간, 그리고 어디까지 복구 대상으로 둘지가 비용을 정해요. 모든 데이터를 똑같이 자주·오래 보관하면 비용이 커지니, 핵심 데이터와 그렇지 않은 데이터를 나눠 정책을 다르게 두면 돼요. 이 구조는 유지보수 비용 가이드에서 더 자세히 다뤄요.

백업만 잘 받아두면 복구는 나중에 준비해도 되지 않나요?

복구 절차는 평소에 만들어두지 않으면 정작 급할 때 처음 해보게 돼요. 그때는 시간도 오래 걸리고 실수도 나기 쉬워요. 백업을 설정하는 단계에서 “이걸로 어떻게, 얼마 만에 되살릴지”를 같이 정해두는 걸 권해요.