재해 복구 시나리오에서의 목표 복구 시간 산정을 위한 데이터 전송량 계산
증상 확인: 복구 시간이 예상보다 훨씬 길어지는 문제
재해 복구 계획을 수립하거나 테스트할 때 가장 흔히 맞닥뜨리는 현실적 문제입니다. 백업은 완벽하게 존재하고, 복구 절차도 문서화되어 있습니다, 그러나 구체적으로 rto를 달성하려고 시도하면, 데이터 전송 속도가 병목이 되어 목표 시간 내에 시스템을 가동할 수 없다는 사실을 깨닫게 됩니다. 이는 단순한 계산 오류가 아닌, 네트워크 대역폭, 데이터 변화량, 압축 효율 등 여러 변수를 간과한 결과입니다.
원인 분석: 왜 복구 시간 계산은 틀리는가
목표 복구 시간을 산정할 때 많은 조직이 ‘전체 백업 데이터량 / 네트워크 대역폭’이라는 단순한 공식을 사용합니다. 이는 치명적인 오류를 유발합니다. 첫째, 대역폭은 이론적 최대치이며, 실제 사용 가능한 처리량은 훨씬 낮습니다. 둘째, 초기 전체 백업 이후의 증분 또는 차등 백업 데이터만을 전송해야 하는지 고려하지 않습니다. 셋째, 데이터 압축, 암호화 오버헤드, 네트워크 프로토콜의 효율성, 심지어 복구 대상 스토리지의 쓰기 성능까지 전체 체인의 가장 약한 링크가 최종 RTO를 결정합니다.
해결 방법 1: 기본적인 데이터 전송량 계산 공식 적용
가장 기초적인 수준에서, 필요한 데이터 전송량을 파악하는 것부터 시작해야 합니다. 여기에는 두 가지 주요 시나리오가 존재합니다.
시나리오 A: 전체 백업 데이터를 재해 복구 사이트로 전송하는 경우
이 경우 계산은 비교적 단순합니다. 그러나 ‘전체 데이터량’을 정확히 측정하는 것이 핵심입니다.
- 복구가 필요한 시스템 또는 데이터셋의 총 용량 확인: 파일 서버라면 사용 중인 디스크 공간, 데이터베이스라면 데이터 파일의 총 크기를 확인합니다. ‘할당된 용량’이 아닌 ‘실제 사용 용량’을 기준으로 삼아야 합니다. Windows에서는
dir명령어나 속성 창. Linux에서는df -h및du -sh명령어를 활용합니다. - 네트워크 대역폭의 실제 처리량 산정: 1gbps(기가비트 per second) 회선은 이론상 초당 125mb(메가바이트)를 전송할 수 있습니다. 그러나 TCP/IP 오버헤드, 네트워크 혼잡, 암호화 등으로 인해 실제 사용 가능한 처리량은 이론치의 70~80% 수준, 즉 초당 약 87.5MB~100MB 정도로 봐야 합니다. 실제 테스트는
iperf3나ttcp같은 도구로 측정하는 것이 가장 정확합니다. - 기본 공식 적용: 필요한 전송 시간(초) = 총 데이터 용량(Byte) / 실제 네트워크 처리량(Byte/초). 결과를 시간 단위로 변환하여 RTO 목표와 비교합니다.
시나리오 B: 마지막 전체 백업 + 이후의 변경분만 전송하는 경우
현실적인 대부분의 재해 복구는 이 방식입니다. RPO(목표 복구 시점)에 따라 전송해야 할 데이터량이 결정됩니다.
- RPO 결정: 데이터를 얼마나 과거의 상태로 복구할 수 있어야 합니까? 24시간, 4시간, 1시간 단위인지 명확히 합니다.
- 변경 데이터량 산정: RPO 기간 동안 생성되거나 변경된 데이터의 양을 측정합니다. 백업 솔루션의 리포트 기능을 사용하거나, 파일 시스템의 변경 로그, 데이터베이스 트랜잭션 로그 크기를 기준으로 추정합니다.
- 전송량 계산: 재해 발생 시, 복구 사이트에 존재하는 최신 전체 백업 이후(RPO 기간 내)의 변경 데이터만 전송하면 됩니다. 그래서 전송 시간 = (변경 데이터량) / (실제 네트워크 처리량) 으로 계산합니다.
주의사항: 이 계산은 ‘데이터 전송’ 시간만을 고려한 것입니다, 데이터를 전송받은 후, 복구 사이트의 스토리지에 기록하고, 애플리케이션을 마운트 또는 시작하는 시간은 별도로 추가되어야 합니다. 이는 종종 전송 시간보다 더 오래 걸릴 수 있습니다.
해결 방법 2: 고급 변수 및 압축 효율 반영 계산
실제 엔터프라이즈 환경에서는 더 복잡한 변수들을 고려해야 정확한 산정이 가능합니다. 이처럼 method 1의 공식을 보완하는 고급 계산법입니다.
핵심 변수들:
- 압축률: 백업 솔루션은 대부분 데이터를 압축합니다. 텍스트, 로그 파일은 높은 압축률(60% 이상)을, 이미지, 동영상, 이미 압축된 파일은 낮은 압축률(10~20%)을 보입니다. 평균 2:1(50%) 압축률을 가정하는 것이 일반적입니다.
- 중복제거 효율: 스토리지나 백업 솔루션 수준의 중복제거를 사용한다면, 전송해야 할 실제 데이터량은 크게 줄어듭니다, 초기 전체 백업 시 중복제거 효율이 90%에 달할 수도 있으나, 증분 백업 시에는 효율이 낮아집니다.
- 암호화 오버헤드: 전송 구간 암호화(예: ipsec, ssl/tls)는 cpu 성능을 소모하며, 순수 데이터 처리량을 약 5~15% 감소시킬 수 있습니다.
개선된 계산 공식:
- 전송 대상 순수 데이터량(d) 확정: rpo에 따라 전체 백업 데이터량인지, 변경분 데이터량인지 결정합니다.
- 압축 및 중복제거 적용: 예상 압축률(c)과 중복제거율(de)을 적용합니다. 특히, 1TB 데이터에 평균 50% 압축률과 70% 중복제거율을 기대한다면, 전송 전 데이터량은 1TB * 0.5 * (1-0.7) = 150GB로 계산됩니다. 이 수치는 백업 솔루션 벤더의 스펙시트나 실제 테스트를 통해 얻어야 합니다.
- 실제 네트워크 처리량(N) 측정: 암호화 오버헤드를 포함한 종단 간 실제 처리량을
iperf3등으로 측정합니다. - 최종 계산: 예상 전송 시간(초) = (D * (1-C) * (1-De)) / N. 여기서 C와 De는 소수로 표현합니다(예: 50% -> 0.5).
WAN 가속 장비의 영향도 계산
전용 WAN 가속 장비를 사용할 경우, 계산은 근본적으로 달라집니다. 이 장비들은 프로토콜 최적화, 데이터 중복 제거(전송 구간), 압축 가속을 통해 효과적인 대역폭을 극대화합니다. 특히 관리자 활동 로그의 보관 기간 정책과 스토리지 비용 최적화를 통해 전송할 원천 데이터의 부피를 미리 줄여둔다면, 가속 장비의 중복 제거 효율은 더욱 극대화될 수 있습니다. 이 경우, 벤더에서 제공하는 ‘효과적인 대역폭 배율’을 사용해야 합니다.
이 경우, 벤더에서 제공하는 ‘효과적인 대역폭 배율’을 사용해야 합니다. 예를 들어, 10배의 가속 효율을 제공한다고 명시된 장비를 100Mbps 회선에 배치했다면, 계산에 사용할 수 있는 처리량(N)은 100Mbps * 10 = 1Gbps에 해당하는 처리량으로 간주할 수 있습니다. 반드시 실제 POC(Proof of Concept) 테스트를 통해 해당 환경에서의 실제 배율을 확인하는 작업이 선행되어야 합니다.
해결 방법 3: 실제 테스트와 모니터링을 통한 검증
어떤 이론적 계산도 한 번의 실제 테스트보다 정확하지 않기에 계산으로 도출된 결과가 타당한지 반드시 검증해야 합니다. 파일럿 테스트 설계를 위해 재해 복구 목표 시간(RTO)의 이론적 배경과 정의를 시스템 복구 메커니즘에 대입하여 분석해 보면, 전체 데이터가 아닌 대표성 있는 일부 시스템을 선정하여 데이터 특성을 먼저 파악하는 과정이 핵심임을 알 수 있습니다. 주말이나 업무 외 시간을 활용해 실제 절차를 수행하며 네트워크 모니터링 및 리소스 분석 도구로 병목 현상의 원인을 파악하고, 도출된 결과로 계산 변수를 보정하여 재해 복구 계획서에 명시적으로 문서화해야 합니다. 이러한 실무적 검증은 이론적 수치와 실제 운영 환경 사이의 간극을 좁히는 필수적인 단계입니다.
주의사항 및 예방 조치
정확한 수치 산출 외에도 재해 복구의 성공 가능성을 높이기 위해 점검해야 할 필수 요건들이 존재합니다. 대역폭은 공유 자원이기에 재해 발생 시 타 업무 트래픽과의 간섭을 방지할 QoS 정책을 수립하고 사전에 테스트해야 합니다. 스토리지 부하 처리 역량 역시 중요하며, 특히 클라우드 환경에서는 프로비저닝된 IOPS 옵션이 적절히 할당되었는지 검증이 요구됩니다. RPO와 RTO의 상관관계를 분석하는 과정에서 확인된 http://www.blubel.co 사례처럼 목표 복구 지점을 짧게 설정할수록 실시간 데이터 전송을 위한 네트워크 자원과 처리 성능의 상시 확보가 수반되어야 합니다. 최신 백업 기술인 ‘증분 영구성’ 방식을 활용하면 특정 시점의 이미지 하나만 원격지로 복제하여 복구 시간(RTO)을 효과적으로 단축할 수 있으므로, 솔루션 도입 시 해당 메커니즘의 지원 여부를 면밀히 확인해야 합니다.