재해 복구 계획(DR) 수립 방법 (RTO와 RPO)

재해 복구 계획을 수립하기 위한 실용적이고 단계별로 정리된 가이드입니다. 현실적인 RTO와 RPO 목표를 설정하는 방법, 비즈니스 영향 분석을 수행하는 방법, 계층형 백업 전략을 설계하는 방법, 그리고 실제로 필요해지기 전에 복구를 테스트하는 방법을 다룹니다.

SKYLINE Engineering @skyline

2026년 6월 9일 게시 | 읽는 시간: 6분

재해 복구 계획이란 실제로 무엇인가

재해 복구(DR) 계획은 장애 발생 후 IT 시스템과 데이터를 복원하기 위해 팀이 따르는, 문서화되고 테스트된 절차입니다. 여기서 장애란 서버 고장, 랜섬웨어, 데이터베이스 삭제, 데이터센터 침수, 클라우드 리전 장애 등을 말합니다. 이는 백업과는 다릅니다. 백업은 데이터의 사본이고, DR 계획은 그 사본을 다시 운영 가능한 비즈니스로 되돌리는 플레이북입니다.

모든 DR 계획의 기준이 되는 두 가지 수치가 있습니다. 바로 RTO와 RPO입니다. 이 두 가지를 제대로 설정하면 나머지 계획은 거의 저절로 완성됩니다.

RTO와 RPO: 가장 중요한 두 가지 수치

• 목표 복구 시간(RTO, Recovery Time Objective) 은 시스템이 심각한 피해를 유발하기 전까지 다운된 상태로 허용할 수 있는 최대 시간입니다. 전자상거래 사이트의 RTO가 2시간이라면, 복구는 사고 발생 후 2시간 이내에 완료되어야 합니다.
• 목표 복구 시점(RPO, Recovery Point Objective) 은 시간 단위로 측정한, 손실을 감수할 수 있는 데이터의 최대량입니다. RPO가 15분이라는 것은 백업(또는 복제)이 15분보다 오래되지 않아야 함을 뜻하며, 따라서 최대 15분 분량의 작업만 손실됨을 의미합니다.

쉽게 기억하는 방법: RTO는 앞을 본다("얼마나 지나야 복구되는가?"), 그리고 RPO는 뒤를 본다("최근 데이터를 얼마나 잃을 수 있는가?").

목표가 엄격할수록 비용이 더 들기 때문에, 모든 시스템에 한꺼번에가 아니라 워크로드별로 목표를 설정해야 합니다.

1단계: 비즈니스 영향 분석(BIA) 수행

모든 시스템을 나열하고 다음을 질문하세요. 이 시스템이 다운될 때 매 시간 비즈니스에 어떤 일이 발생하며, 어느 정도의 데이터 손실을 감내할 수 있는가? 그런 다음 워크로드를 계층으로 분류하세요.

솔직해야 합니다. 마케팅 블로그에 5분 RTO를 부여하는 것은 돈 낭비이고, 결제 원장에 24시간 RPO를 두는 것은 사업을 끝장낼 수 있는 실수입니다.

2단계: 계층별 복구 전략 선택

각 계층을 적절한 아키텍처에 매칭하세요.

• 백업 및 복원(가장 저렴하고 가장 느림): 오브젝트 스토리지로 예약 백업을 수행하고 필요 시 재구축. 계층 3과 다수의 계층 2 워크로드에 적합합니다.
• 파일럿 라이트 / 웜 스탠바이: 환경의 최소 사본을 두 번째 위치에서 가동해 두었다가 페일오버 시 규모를 확대. 적당한 RTO를 가진 계층 1에 적합합니다.
• 핫 스탠바이 / 액티브-액티브: 완전히 가동 중인 복제본이 거의 즉시 인계받는 방식. 비용이 가장 높으며, 단 몇 분의 다운타임도 용납되지 않는 계층 1 시스템에만 사용하세요.

사우디 조직의 경우, 각 사본이 물리적으로 어디에 위치하는지도 확인하세요. PDPL과 NCA 지침에 따라, 주(primary) 사본과 DR 사본을 국내(in-Kingdom) 클라우드 인프라에 보관하면 데이터 주권(데이터 거주) 요건을 충족하고 국경 간 데이터 이전 심사를 피할 수 있습니다.

3단계: 3-2-1 백업 규칙 적용

계층이 무엇이든, 검증된 3-2-1 규칙을 기준으로 백업을 설계하세요.

• 데이터 사본 3개(주 사본 1개 + 백업 2개)
• 서로 다른 매체 또는 스토리지 유형 2개
• 오프사이트(다른 리전 또는 다른 제공자) 사본 1개

현대적 변형인 3-2-1-1-0은 불변(immutable)/오프라인 사본 1개(랜섬웨어 방어)와 복원 시 검증된 오류 0개를 추가합니다. 불변성은 중요합니다. 이제 랜섬웨어는 백업을 가장 먼저 노립니다.

다음은 restic을 사용해 데이터베이스와 앱 디렉터리를 S3 호환 오브젝트 스토리지로 안정적으로, 중복 제거 및 암호화하여 백업하는 예시입니다.

# Install restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic

# Point restic at your object storage bucket
export RESTIC_REPOSITORY="s3:https://s3.example.com/dr-backups"
export AWS_ACCESS_KEY_ID="<access-key>"
export AWS_SECRET_ACCESS_KEY="<secret-key>"
export RESTIC_PASSWORD="<strong-repo-passphrase>"   # keep this safe & off-server

# One-time: initialise the encrypted repository
restic init

# Dump the database, then back up the dump + app files
mysqldump --single-transaction --routines --triggers \
  -u backup -p"$DB_PASS" appdb > /var/backups/appdb.sql

restic backup /var/backups/appdb.sql /srv/app --tag nightly

# Enforce retention (keeps storage and RPO sane)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

백업 빈도는 반드시 RPO를 충족해야 합니다. RPO가 1시간이라면 cron으로 작업을 매시간 예약하고, 매 실행이 해당 시간 내에 충분히 여유 있게 완료되는지 확인하세요.

# /etc/cron.d/dr-backup — hourly backup at minute 5
5 * * * * root /usr/local/bin/dr-backup.sh >> /var/log/dr-backup.log 2>&1

데이터베이스에 더 엄격한 RPO가 필요하다면, 스냅샷에만 의존하지 말고 연속적인 방식 — MySQL/MariaDB 바이너리 로그 시핑이나 PostgreSQL WAL 아카이빙 / 스트리밍 복제 — 을 사용하세요.

4단계: 복구 런북 작성

아무도 압박 속에서 복원하지 못하는 백업은 무용지물입니다. 당직 중인 누구라도 따를 수 있도록 정확한 복원 단계를 런북으로 문서화하세요.

1. 사고를 선언하고 DR 코디네이터에게 알립니다.
2. 복구 인프라를 프로비저닝합니다(빠르게 가동할 수 있는 스탠바이 클라우드 서버 또는 호스팅 환경).
3. 가장 최근의 검증된 백업에서 데이터를 복원합니다.
4. 무결성을 검증한 다음, 트래픽을 전환합니다(DNS/로드밸런서).
5. 이해관계자에게 상황을 전달합니다.

위의 restic 예시에서의 복원은 간단히 다음과 같습니다.

# List recovery points, then restore the latest into a target path
restic snapshots
restic restore latest --target /srv/recovery

런북에는 이름, 전화번호, 그리고 자격 증명이 보관된 위치(자격 증명 자체가 아니라)를 함께 두되, 주 시스템이 다운되더라도 접근할 수 있는 곳에 보관하세요.

5단계: 테스트하고, 또 테스트하기

DR 계획은 방치하면 썩습니다. 계층 1 시스템에 대해서는 최소 분기마다 복구 훈련을 예약하세요.

• 탁상 훈련(Tabletop test): 런북을 문서상으로 따라가 봅니다.
• 복원 테스트(Restore test): 백업을 격리된 환경에 실제로 복원하고 데이터가 올바른지 확인합니다(3-2-1-1-0의 "0").
• 전체 페일오버(Full failover): DR 사이트로 전환하여 그 위에서 운영합니다.

각 훈련 후에는 실제 복구 시간과 데이터 손실을 RTO 및 RPO와 비교해 측정하세요. 목표를 달성하지 못했다면 격차를 해소하고 — 더 잦은 백업, 더 많은 자동화, 또는 더 따뜻한(warm) 스탠바이 — 다시 테스트하세요.

종합하기

실효성 있는 DR 계획은 간결합니다. 한 페이지짜리 계층 분류 표, 계층별 RTO/RPO 목표, 3-2-1-1-0 백업 설계, 테스트된 런북, 그리고 훈련 일정이면 됩니다. 가장 핵심적인 워크로드부터 시작해 복원이 처음부터 끝까지 작동함을 입증한 다음, 계층별로 확장하세요.

PDPL과 NCA 컴플라이언스를 위해 백업과 스탠바이 인프라를 국내(Kingdom)에 두고 싶다면, 관련 가이드를 보려면 클라우드 백업 클러스터를 살펴보거나, Skyline Cloud 계정을 생성하여 몇 분 만에 국내 오브젝트 스토리지, 클라우드 서버, 백업을 프로비저닝하세요.

이 가이드가 유용했나요? 예 · 아니요 (0표)

SKYLINE Engineering @skyline

SKYLINE Industrial Solutions의 엔지니어링 팀입니다. 우리는 실제 KSA 및 GCC 배포에서 얻은 현장 검증된 가이드를 게시합니다.

작성자 프로필 보기

관련 튜토리얼

모든 Skyline Cloud 가이드 →

• Skyline Cloud: 새 VPS 보안 설정 방법: 방화벽 및 SSH 강화 — SKYLINE Engineering · 5분 읽기

• Skyline Cloud: 如何加固新的 VPS：防火墙与 SSH 安全强化 — SKYLINE Engineering · 3분 읽기

• Skyline Cloud: नए VPS को सुरक्षित कैसे करें: फ़ायरवॉल और SSH हार्डनिंग — SKYLINE Engineering · 10분 읽기

SKYLINE 엔지니어링 서비스

직접 구축해 드릴까요?

읽는 것은 무료지만, 제대로 구축하는 데는 팀이 필요합니다. SKYLINE 엔지니어는 사우디아라비아 전역의 Aramco 협력업체, 은행, 병원, 정부 기관을 위해 Skyline Cloud를 제공합니다. 시작하기 전에 저희와 상담하세요.

• 🛡 사이버보안 및 데이터센터 SACS-210, NCA ECC, SOC, 24/7 운영
• 🛠 IT AMC 연간 유지보수, 24/7 SLA, Bronze→Platinum

SKYLINE 엔지니어와 상담하기 | WhatsApp · +966 50 993 9334 | 전화 +966 50 993 9334

Aramco 승인 협력업체 | ISO 9001 · ISO 27001 | SAMA CSF 준수 | NCA ECC 준비 완료 | 247+ KSA 고객사

댓글

총 0개 · 0개 스레드

토론에 참여하려면 로그인하세요. 처음이신가요? 계정 만들기.

가장 먼저 댓글을 남겨보세요.