재해 복구 시나리오에서의 목표 복구 시간 산정을 위한 데이터 전송량 계산

증상 확인: 복구 시간이 예상보다 훨씬 길어지는 문제

재해 복구 계획을 수립하거나 테스트할 때 가장 흔히 맞닥뜨리는 현실적 문제입니다. 백업은 완벽하게 존재하고, 복구 절차도 문서화되어 있습니다, 그러나 구체적으로 rto를 달성하려고 시도하면, 데이터 전송 속도가 병목이 되어 목표 시간 내에 시스템을 가동할 수 없다는 사실을 깨닫게 됩니다. 이는 단순한 계산 오류가 아닌, 네트워크 대역폭, 데이터 변화량, 압축 효율 등 여러 변수를 간과한 결과입니다.

원인 분석: 왜 복구 시간 계산은 틀리는가

목표 복구 시간을 산정할 때 많은 조직이 ‘전체 백업 데이터량 / 네트워크 대역폭’이라는 단순한 공식을 사용합니다. 이는 치명적인 오류를 유발합니다. 첫째, 대역폭은 이론적 최대치이며, 실제 사용 가능한 처리량은 훨씬 낮습니다. 둘째, 초기 전체 백업 이후의 증분 또는 차등 백업 데이터만을 전송해야 하는지 고려하지 않습니다. 셋째, 데이터 압축, 암호화 오버헤드, 네트워크 프로토콜의 효율성, 심지어 복구 대상 스토리지의 쓰기 성능까지 전체 체인의 가장 약한 링크가 최종 RTO를 결정합니다.

해결 방법 1: 기본적인 데이터 전송량 계산 공식 적용

가장 기초적인 수준에서, 필요한 데이터 전송량을 파악하는 것부터 시작해야 합니다. 여기에는 두 가지 주요 시나리오가 존재합니다.

시나리오 A: 전체 백업 데이터를 재해 복구 사이트로 전송하는 경우

이 경우 계산은 비교적 단순합니다. 그러나 ‘전체 데이터량’을 정확히 측정하는 것이 핵심입니다.

1. 복구가 필요한 시스템 또는 데이터셋의 총 용량 확인: 파일 서버라면 사용 중인 디스크 공간, 데이터베이스라면 데이터 파일의 총 크기를 확인합니다. ‘할당된 용량’이 아닌 ‘실제 사용 용량’을 기준으로 삼아야 합니다. Windows에서는 dir 명령어나 속성 창. Linux에서는 df -h 및 du -sh 명령어를 활용합니다.
2. 네트워크 대역폭의 실제 처리량 산정: 1gbps(기가비트 per second) 회선은 이론상 초당 125mb(메가바이트)를 전송할 수 있습니다. 그러나 TCP/IP 오버헤드, 네트워크 혼잡, 암호화 등으로 인해 실제 사용 가능한 처리량은 이론치의 70~80% 수준, 즉 초당 약 87.5MB~100MB 정도로 봐야 합니다. 실제 테스트는 iperf3나 ttcp 같은 도구로 측정하는 것이 가장 정확합니다.
3. 기본 공식 적용: 필요한 전송 시간(초) = 총 데이터 용량(Byte) / 실제 네트워크 처리량(Byte/초). 결과를 시간 단위로 변환하여 RTO 목표와 비교합니다.

시나리오 B: 마지막 전체 백업 + 이후의 변경분만 전송하는 경우

현실적인 대부분의 재해 복구는 이 방식입니다. RPO(목표 복구 시점)에 따라 전송해야 할 데이터량이 결정됩니다.

1. RPO 결정: 데이터를 얼마나 과거의 상태로 복구할 수 있어야 합니까? 24시간, 4시간, 1시간 단위인지 명확히 합니다.
2. 변경 데이터량 산정: RPO 기간 동안 생성되거나 변경된 데이터의 양을 측정합니다. 백업 솔루션의 리포트 기능을 사용하거나, 파일 시스템의 변경 로그, 데이터베이스 트랜잭션 로그 크기를 기준으로 추정합니다.
3. 전송량 계산: 재해 발생 시, 복구 사이트에 존재하는 최신 전체 백업 이후(RPO 기간 내)의 변경 데이터만 전송하면 됩니다. 그래서 전송 시간 = (변경 데이터량) / (실제 네트워크 처리량) 으로 계산합니다.

주의사항: 이 계산은 ‘데이터 전송’ 시간만을 고려한 것입니다, 데이터를 전송받은 후, 복구 사이트의 스토리지에 기록하고, 애플리케이션을 마운트 또는 시작하는 시간은 별도로 추가되어야 합니다. 이는 종종 전송 시간보다 더 오래 걸릴 수 있습니다.

해결 방법 2: 고급 변수 및 압축 효율 반영 계산

실제 엔터프라이즈 환경에서는 더 복잡한 변수들을 고려해야 정확한 산정이 가능합니다. 이처럼 method 1의 공식을 보완하는 고급 계산법입니다.

핵심 변수들:

• 압축률: 백업 솔루션은 대부분 데이터를 압축합니다. 텍스트, 로그 파일은 높은 압축률(60% 이상)을, 이미지, 동영상, 이미 압축된 파일은 낮은 압축률(10~20%)을 보입니다. 평균 2:1(50%) 압축률을 가정하는 것이 일반적입니다.
• 중복제거 효율: 스토리지나 백업 솔루션 수준의 중복제거를 사용한다면, 전송해야 할 실제 데이터량은 크게 줄어듭니다, 초기 전체 백업 시 중복제거 효율이 90%에 달할 수도 있으나, 증분 백업 시에는 효율이 낮아집니다.
• 암호화 오버헤드: 전송 구간 암호화(예: ipsec, ssl/tls)는 cpu 성능을 소모하며, 순수 데이터 처리량을 약 5~15% 감소시킬 수 있습니다.

개선된 계산 공식:

1. 전송 대상 순수 데이터량(d) 확정: rpo에 따라 전체 백업 데이터량인지, 변경분 데이터량인지 결정합니다.
2. 압축 및 중복제거 적용: 예상 압축률(c)과 중복제거율(de)을 적용합니다. 특히, 1TB 데이터에 평균 50% 압축률과 70% 중복제거율을 기대한다면, 전송 전 데이터량은 1TB * 0.5 * (1-0.7) = 150GB로 계산됩니다. 이 수치는 백업 솔루션 벤더의 스펙시트나 실제 테스트를 통해 얻어야 합니다.
3. 실제 네트워크 처리량(N) 측정: 암호화 오버헤드를 포함한 종단 간 실제 처리량을 iperf3 등으로 측정합니다.
4. 최종 계산: 예상 전송 시간(초) = (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가 타당한지 반드시 검증해야 합니다.

1. 파일럿 테스트 설계: 전체 프로덕션 데이터가 아닌, 대표성이 있는 일부 시스템(예: 부서별 파일 서버 1대, 핵심 DB 1개)을 선정합니다. 이 시스템의 데이터 특성(파일 유형, 크기, 변경 빈도)이 전체와 유사해야 합니다.
2. 제어된 복구 테스트 실행: 주말이나 업무 외 시간을 이용해 실제 재해 복구 절차를 따라 데이터 전송 및 복구를 수행합니다. 전체 과정을 시간 측정합니다.
3. 병목 현상 분석: 테스트 중 네트워크 모니터링 도구(예: Wireshark, 네트워크 스위치의 포트 카운터)와 시스템 리소스 모니터링 도구(예: Windows Performance Monitor, Linux top, iostat)를 동시에 실행합니다. 데이터 전송 속도가 예상보다 낮다면, 네트워크 지연, 패킷 손실, 복구 대상 스토리지의 디스크 I/O 한계, 백업 서버의 CPU 성능 중 어디에서 병목이 발생하는지 정확히 파악합니다.
4. 계산식 보정 및 문서화: 테스트 결과를 바탕으로 이전 단계의 계산 공식에 사용한 변수들(실제 처리량 N, 압축률 C 등)을 보정합니다, 이 보정된 공식과 테스트 결과를 재해 복구 계획서에 명시적으로 문서화합니다.

주의사항 및 예방 조치

정확한 계산 외에도 재해 복구의 성공을 보장하기 위해 체크해야 할 필수 사항입니다.

• 대역폭은 공유 자원: 재해 복구 전용 회선이 아니라면, 재해 발생 시 다른 업무 트래픽과 경쟁하게 됩니다. 복구 작업이 다른 중요 업무에 영향을 주지 않도록 QoS 정책을 미리 수립하고 테스트해야 합니다.
• 스토리지 쓰기 성능 검증 필수: 데이터를 아무리 빨리 전송해도, 복구 사이트의 스토리지가 그 속도를 따라 쓰지 못하면 무용지물입니다. 특히 클라우드 스토리지를 복구 대상으로 할 경우, Provisioned IOPS 등 쓰기 성능 옵션을 충분히 할당했는지 확인해야 합니다.
• RPO와 RTO의 트레이드오프 인식: RPO를 5분으로 설정하면 데이터 손실은 적지만, 초당 생성되는 변경 데이터를 거의 실시간으로 전송해야 하므로 상시적인 네트워크 대역폭과 처리 리소스가 필요합니다. RTO를 1시간으로 설정하려면, 그 시간 내에 전송과 복구를 완료할 수 있는 충분한 대역폭과 성능이 보장되어야 합니다. 둘 다를 극단적으로 낮추는 것은 비용을 기하급수적으로 증가시킵니다.

전문가 팁: 증분 영구성 스냅샷 활용
최신 스토리지 및 백업 기술은 ‘증분 영구성’ 방식을 제공합니다. 초기 전체 백업 후, 매 스냅샷은 이전 상태와의 차이만을 저장하며, 각 스냅샷은 독립적으로 마운트 가능한 전체 이미지로 관리됩니다. 재해 복구 관점에서 이 방식의 핵심 장점은 복구 시점에 ‘전체 백업 + N개의 증분 로그’를 순차적으로 적용할 필요가 없다는 점입니다. 특정 시점의 스냅샷 하나만을 원격지로 복제하면 되므로. 복구 시간 계산이 훨씬 단순해지고 rto를 크게 단축할 수 있습니다. 솔루션 도입 시 이 기능의 지원 여부와 복제 메커니즘을 반드시 확인하십시오.