재해 복구(DR) 관점에서 보는 백업 정책 — RTO·RPO 설정부터 시작하기

백업은 있는데 왜 복구는 실패할까

많은 기업이 백업 시스템을 이미 운영하고 있지만, 정작 장애가 발생했을 때 "얼마나 빨리", "어느 시점까지" 복구할 수 있는지는 명확히 정의해두지 않은 경우가 많습니다. 백업 작업 자체는 매일 정상적으로 돌아가더라도, 복구 시나리오를 사전에 점검하지 않으면 실제 장애 상황에서 예상보다 훨씬 긴 다운타임을 겪을 수 있습니다.

백업과 재해복구(DR, Disaster Recovery)는 목적이 다릅니다. 백업이 '데이터를 잃지 않는 것'에 초점을 둔다면, 재해복구는 '업무를 얼마나 빨리 정상화할 수 있는가'까지 포함하는 개념입니다.

RTO·RPO, 목표를 먼저 정해야 하는 이유

재해복구 계획의 출발점은 RTO(Recovery Time Objective, 목표 복구 시간)와 RPO(Recovery Point Objective, 목표 복구 시점)를 정의하는 것입니다. RTO는 장애 발생 후 서비스나 시스템을 정상화하는 데 허용 가능한 최대 시간을, RPO는 복구 시 감수할 수 있는 최대 데이터 손실 범위(마지막 백업 시점 기준)를 의미합니다.

업무 시스템마다 중요도가 다르기 때문에, 전사 공통 목표 하나만 세우기보다는 핵심 업무 시스템과 부가 시스템을 구분해 우선순위별로 RTO·RPO를 다르게 설정하는 방식이 현실적입니다. 이 기준이 명확해야 백업 주기, 보관 방식, 복구 절차 설계가 뒤따라올 수 있습니다.

온프레미스·클라우드·하이브리드, 구조에 따라 달라지는 것들

백업 인프라는 크게 온프레미스 자체 구축, 클라우드 기반, 그리고 두 방식을 함께 사용하는 하이브리드 구조로 나눌 수 있습니다. 온프레미스는 내부 통제와 네트워크 의존도 면에서 강점이 있는 반면, 별도 재해 발생 시 동일 사업장의 백업본까지 함께 영향을 받을 위험이 있습니다. 클라우드 백업은 물리적으로 분리된 위치에 데이터를 보관할 수 있다는 점에서 재해복구 관점에 유리하지만, 네트워크 대역폭과 복구 소요 시간을 함께 고려해야 합니다.

정답은 하나로 정해져 있지 않습니다. 시스템의 중요도, 데이터 양, 규제 요건, 예산 상황에 따라 구조를 조합하는 것이 일반적이며, 핵심은 '어떤 방식이든 실제로 복구가 가능한 상태인지'를 검증해두는 것입니다.

복구 테스트를 정기 업무로 만들기

백업이 정상적으로 수행되고 있다는 로그만으로는 복구 가능 여부를 보장할 수 없습니다. 실제 복구 절차를 주기적으로 테스트해보지 않으면, 백업 파일 손상이나 설정 누락 같은 문제를 장애 상황이 닥쳐서야 발견하게 될 수 있습니다. 복구 테스트를 연 1회 이벤트가 아니라 분기 단위 등 정기 점검 업무로 편입하고, 테스트 결과와 소요 시간을 기록해 RTO 목표와 실제 성능 간 격차를 지속적으로 확인하는 것이 바람직합니다.

환경에 맞는 백업·재해복구 전략이 궁금하다면

적정 백업 주기, 백업 구조(온프레미스/클라우드/하이브리드), RTO·RPO 목표 수립은 기업의 시스템 구성과 업무 특성에 따라 달라집니다. 현재 백업 환경을 점검하고 우리 조직에 맞는 재해복구 전략을 세우고 싶다면, 환경에 맞춰 컨설팅을 받아보시기 바랍니다.