재해 복구
더 많은 작업
- Disaster Recovery
- 화재, 홍수, 지진, 대규모 정전, 사이버 공격 등으로 정보시스템이 중단되었을 때 IT 시스템과 데이터를 정해진 목표 시간 안에 되살리는 활동과 이를 위한 설비·계획
재해 복구(DR)는 업무 연속성 계획(BCP)의 IT 부분을 맡는다. 업무 영향 분석으로 어떤 시스템을 얼마나 빨리, 어느 시점의 데이터로 되살려야 하는지 정하고, 그 목표에 맞는 복구 설비(대체 사이트)와 데이터 백업·복제 방식을 갖춘 뒤, 절차를 재해 복구 계획으로 문서화하고 재해 복구 훈련으로 검증한다.
- 업무 환경과 거의 동일한 환경으로 동기화되고 있거나, 함께 보조적으로 운영된다.
- RTO : 0 또는 수분 이내
- 재난 발생으로 영향을 받는 업무 기능을 즉시 복구할 수 있도록 전산센터와 동일한 모든 설비와 자원을 보유하고 있다.
- RTO : 4시간 이내
- 재해복구센터에 주 센터와 동일한 수준의 시스템을 대기상태로 둔다.
- 실시간 데이터 복제를 통하여 최신의 데이터 상태를 유지
- 재해 시 재해복구센터의 시스템을 활성화 상태로 전환하여 복구
부분적으로 설비를 가지고 있는 백업 사이트로서, 대개 디스크 드라이브, 테이프 드라이브와 같이 가격이 저렴한 주변기기를 가지고 있으나, 주 컴퓨터는 가지고 있지 않다.
- RTO : 수일 이내
재난 발생시 새로운 컴퓨터를 설치할 수 있는 컴퓨터실을 미리 준비해 둔 것으로서 전기, 냉방, 공간 정도만 마련되어 있으며 별다른 전산 장비는 가지고 있지 않다.
- RTO : 수주 ~ 1개월
모바일 사이트(mobile site)는 필요한 통신·시스템 장비를 갖춘 이동식 독립형 시설(트레일러, 컨테이너 등)이다. NIST SP 800-34 Rev.1은 많은 경우 원하는 장소까지 24시간 안에 옮길 수 있지만, 장비 설치와 구성 시간이 더해진다고 설명한다. 주 사이트 가까이에 세울 수 있어 인력 이동 부담이 적다.
상호 지원 협약(reciprocal agreement)은 비슷한 시스템 구성을 가진 둘 이상의 조직이 재해 시 서로의 시설을 대체 사이트로 쓰기로 약정하는 것이다. 비용이 거의 들지 않지만 각 조직이 자기 업무에 더해 상대 업무까지 처리할 여유가 있어야 하고, 시스템 호환성, 상대 조직 인력에게 데이터가 노출될 위험, 같은 지역 재해로 함께 피해를 입을 가능성 때문에 주된 복구 수단으로 삼기 어렵다.
위 RTO 값은 국내 교재와 실무에서 흔히 쓰는 참고치이며 표준이 정한 값은 아니다. NIST SP 800-34 Rev.1은 설치 시간을 콜드 사이트 "김", 웜 사이트 "중간", 핫 사이트 "짧음"처럼 상대적으로만 비교한다. 서비스 사무국, DRaaS, 다중 처리 사이트까지 포함한 비교 표와 자원 용량 협약은 재해 복구 사이트 문서에 정리되어 있다.
| 지표 | 의미 | 결정하는 것 |
|---|---|---|
| 최대 허용 중단 시간(MTD, Maximum Tolerable Downtime) | 업무가 멈춰도 조직이 견딜 수 있는 최대 시간 | 다른 목표의 상한선 |
| RTO(Recovery Time Objective, 복구 시간 목표) | 중단 후 시스템을 복구해야 하는 목표 시간. MTD 이내여야 함 | 복구 사이트 유형, 자동화 수준 |
| RPO(Recovery Point Objective, 복구 시점 목표) | 복구 시 되돌아갈 데이터 시점. 허용 가능한 데이터 손실량 | 백업 주기, 복제 방식 |
| WRT(Work Recovery Time, 업무 복구 시간) | 시스템이 복구된 뒤 데이터 검증, 누락 거래 재입력 등으로 업무를 정상화하는 데 걸리는 시간 | RTO + WRT ≤ MTD가 되도록 설계 |
NIST SP 800-34 Rev.1도 RTO는 MTD를 넘지 않도록 보통 MTD보다 짧아야 하며, 중단으로 밀린 데이터를 다시 처리하는 시간을 RTO에 더해도 MTD 안에 들어야 한다고 설명한다. RPO는 MTD의 일부가 아니라 허용 가능한 데이터 손실의 척도다. 이 지표는 업무 영향 분석에서 시스템별로 정한다. RTO는 어떤 재해 복구 사이트를 둘지를, RPO는 어떤 백업 방식과 복제를 쓸지를 결정한다.
클라우드를 대체 사이트로 쓰면 평소에는 데이터와 서버 이미지만 복제해 두고 재해 때 계산 자원을 띄울 수 있어, 자체 핫·웜 사이트보다 고정비가 낮다. 클라우드 공급자나 DR 사업자가 이를 서비스로 제공하는 것을 DRaaS(Disaster Recovery as a Service)라 한다. 대표적인 구성은 다음과 같다.
| 구성 | 평소 상태 | 대응하는 전통 사이트 |
|---|---|---|
| 백업 후 복원 | 백업만 클라우드 저장소에 보관 | 콜드 사이트 |
| 최소 핵심 환경 유지(파일럿 라이트) | 데이터베이스 복제 등 핵심 요소만 상시 가동 | 콜드~웜 사이트 |
| 축소 운영 대기 | 축소된 규모의 전체 환경을 상시 가동 | 웜 사이트 |
| 다중 사이트 액티브-액티브 | 두 지역에서 동시에 운영 | 미러 사이트 |
클라우드 DR에서도 주 리전과 같은 재해·장애 영향을 받지 않는 지역을 고르고, 복구 계정을 운영 계정과 분리해 계정 탈취나 랜섬웨어로 함께 잃지 않게 하며, 원래 위치로 되돌아오는 페일백 절차를 시험해야 한다. AWS 사례는 AWS 재해 복구 전략에 있다.