백업 설정은 대부분 이렇게 됩니다. Azure Backup을 켜고, 기본 정책(매일 1회, 30일 보관)을 그대로 쓰고, 초록색 체크가 뜨면 끝. 복구를 한 번도 해보지 않은 채 몇 년이 지납니다.
그러다 실제로 복구가 필요해지면 두 가지를 그때 알게 됩니다. 복구에 생각보다 오래 걸린다는 것, 그리고 백업 시점이 필요한 시점보다 훨씬 이전이라는 것입니다. 이 글은 그 두 숫자 — RPO와 RTO — 에서 거꾸로 백업 설계를 끌어내는 방법입니다.
RPO와 RTO를 실제 금액으로 정하기
용어부터 명확히 하겠습니다. 헷갈리면 설계가 어긋납니다.
- RPO (Recovery Point Objective) — 얼마나 잃어도 되는가. 백업 주기가 결정합니다. 하루 1회 백업이면 최대 24시간치 데이터를 잃습니다
- RTO (Recovery Time Objective) — 얼마나 빨리 복구해야 하는가. 복구 방식이 결정합니다
“둘 다 짧을수록 좋다”는 답은 쓸모가 없습니다. 짧게 만들수록 비용이 오르기 때문입니다. 중단 1시간당 손실 금액을 대략이라도 잡아야 판단이 가능합니다.
예를 들어 온라인 주문을 받는 서비스의 시간당 매출이 500만원이라고 하면, 이렇게 비교할 수 있습니다.
| RTO 목표 | 필요한 구성 | 추가 비용 성격 | 4시간 장애 시 손실 |
|---|---|---|---|
| 24시간 | Azure Backup 복원 | 백업 스토리지만 | 2,000만원 |
| 4시간 | Backup + 사전 준비된 스크립트 | 거의 동일 | 2,000만원 |
| 1시간 | Site Recovery (ASR) | 복제 대상 VM당 라이선스 + 스토리지 | 500만원 |
| 수 분 | 다중 리전 액티브-액티브 | 인프라 2벌 | 거의 없음 |
이렇게 놓고 보면 판단이 쉬워집니다. 연 1회 4시간 장애를 가정했을 때 손실이 2,000만원이고, ASR 비용이 연 500만원이라면 ASR이 남는 장사입니다. 반대로 사내 관리 시스템처럼 하루 멈춰도 손실이 크지 않다면 기본 백업으로 충분합니다.
중요한 건 모든 시스템에 같은 목표를 적용하지 않는 것입니다. 시스템별로 등급을 나누는 편이 현실적입니다.
| 등급 | 대상 | RPO | RTO | 방식 |
|---|---|---|---|---|
| Tier 1 | 매출 직결 서비스 | 15분 | 1시간 | ASR + DB 지역 복제 |
| Tier 2 | 내부 업무 시스템 | 24시간 | 8시간 | Azure Backup (일 1회) |
| Tier 3 | 개발·테스트 | 1주 | 상관없음 | IaC로 재생성 |
Tier 3에 주목하실 만합니다. 개발 환경은 백업하지 않는 것이 정답인 경우가 많습니다. Terraform이나 Bicep으로 언제든 다시 만들 수 있다면, 백업 스토리지 비용을 낼 이유가 없습니다.
백업 정책 만들기
Tier 2 기준으로 정책을 만들어보겠습니다. 기본 정책을 그대로 쓰지 않고, 보관 기간을 계층적으로 구성하는 게 핵심입니다.
#!/usr/bin/env bash
set -euo pipefail
RG="rg-backup-prod"
VAULT="rsv-prod-krc-01"
# Recovery Services 자격 증명 모음 생성
az backup vault create \
--name "$VAULT" -g "$RG" --location koreacentral
# 중복 옵션: 지역 중복(GRS)이 기본. 리전 장애까지 대비
az backup vault backup-properties set \
--name "$VAULT" -g "$RG" \
--backup-storage-redundancy GeoRedundant
# VM 백업 활성화
az backup protection enable-for-vm \
--vault-name "$VAULT" -g "$RG" \
--vm "/subscriptions/<SUB>/resourceGroups/rg-prod-app/providers/Microsoft.Compute/virtualMachines/vm-api-prod-krc-01" \
--policy-name DefaultPolicy보관 정책은 일·주·월·연 단위를 조합하는 편이 비용 대비 효율적입니다. 매일 복구 지점을 1년간 들고 있을 필요는 없습니다.
{
"schedulePolicy": {
"schedulePolicyType": "SimpleSchedulePolicy",
"scheduleRunFrequency": "Daily",
"scheduleRunTimes": ["2026-08-01T18:00:00Z"]
},
"retentionPolicy": {
"retentionPolicyType": "LongTermRetentionPolicy",
"dailySchedule": { "retentionDuration": { "count": 30, "durationType": "Days" } },
"weeklySchedule": { "retentionDuration": { "count": 12, "durationType": "Weeks" } },
"monthlySchedule": { "retentionDuration": { "count": 12, "durationType": "Months" } },
"yearlySchedule": { "retentionDuration": { "count": 7, "durationType": "Years" } }
}
}scheduleRunTimes가 UTC 기준이라는 점을 놓치기 쉽습니다. 위 예시의 18:00Z는 한국 시간 새벽 3시입니다. 이걸 모르고 03:00Z로 넣으면 한국 시간 정오에 백업이 돌아 업무 시간 성능에 영향을 줍니다.
복구 시간을 실제로 재본다
여기가 이 글에서 가장 강조하고 싶은 부분입니다. RTO는 문서에 적는 숫자가 아니라 측정하는 숫자입니다.
VM 복원은 단순히 파일을 되돌리는 게 아닙니다. 실제로는 이런 단계를 거칩니다.
- 복구 지점에서 디스크 복원 — 용량에 비례, 수십 분~수 시간
- 복원된 디스크로 VM 재생성
- 네트워크 재구성 — NIC, 공용 IP, 로드밸런서 백엔드 풀 등록
- 확장(Extension) 재설치 — 모니터링 에이전트, 백신 등
- 애플리케이션 기동 및 검증
1번만 생각하고 RTO를 잡으면 반드시 초과합니다. 3~5번이 실제로는 1번보다 오래 걸리는 경우가 흔합니다. 특히 로드밸런서 백엔드 풀 등록이나 DNS 반영을 수동으로 하면 시간이 크게 늘어납니다.
# 복구 지점 목록 확인
az backup recoverypoint list \
--vault-name "$VAULT" -g "$RG" \
--container-name "vm-api-prod-krc-01" \
--item-name "vm-api-prod-krc-01" \
--query "[].{time:properties.recoveryPointTime, type:properties.recoveryPointType}" \
-o table
# 디스크만 복원 (가장 빠른 방식 - 이후 VM은 직접 생성)
az backup restore restore-disks \
--vault-name "$VAULT" -g "$RG" \
--container-name "vm-api-prod-krc-01" \
--item-name "vm-api-prod-krc-01" \
--rp-name "<RECOVERY_POINT_NAME>" \
--storage-account "stbackupstaging001" \
--target-resource-group "rg-restore-test"
# 복원 작업 진행 상황
az backup job list --vault-name "$VAULT" -g "$RG" \
--query "[0].{op:properties.operation, status:properties.status, start:properties.startTime, duration:properties.duration}" \
-o table마지막 명령의 duration이 실측 RTO의 1단계 값입니다. 이걸 분기마다 한 번씩 재보고, 3~5단계를 더해서 실제 RTO를 산출하세요.
복구 훈련은 별도의 리소스 그룹(rg-restore-test)에 복원하면 운영에 영향을 주지 않습니다. 끝나면 리소스 그룹째 지우면 됩니다. 분기 1회, 한 시간이면 충분합니다.
백업이 지켜주지 못하는 것들
VM 백업을 켰다고 전부 보호되는 게 아닙니다. 아래는 별도로 챙겨야 하는 항목들입니다. 복구 상황에서 “이건 백업에 없네”를 발견하면 늦습니다.
| 대상 | VM 백업에 포함? | 필요한 조치 |
|---|---|---|
| Azure SQL Database | ✗ | 자체 자동 백업 + LTR 설정 |
| Blob Storage | ✗ | 버전 관리 + 지점 복원 활성화 |
| Azure Files | ✗ | 파일 공유 백업 별도 설정 |
| Key Vault 시크릿 | ✗ | 소프트 삭제 + 제거 보호 |
| AKS 클러스터 상태 | ✗ | Velero 또는 AKS 백업 |
| 인프라 구성 자체 | ✗ | IaC (Terraform/Bicep) |
마지막 줄이 핵심입니다. VM 데이터는 복원했는데 네트워크·NSG·로드밸런서 설정이 없으면 서비스가 안 뜹니다. 인프라 구성을 코드로 관리하고 있어야 진짜 복구가 가능합니다. 백업 전략의 절반은 IaC라고 봐도 무방합니다.
Key Vault는 특히 주의
Key Vault를 실수로 지우면 그 안의 시크릿·키·인증서가 전부 사라집니다. 제거 보호(Purge Protection)를 켜두면 소프트 삭제 기간 동안 완전 삭제가 불가능해집니다.
az keyvault update \
--name kv-api-prod-krc-01 -g rg-prod-app \
--enable-purge-protection true \
--retention-days 90제거 보호는 한 번 켜면 끌 수 없습니다. 대신 실수로 인한 영구 삭제를 확실히 막아줍니다. 운영 Key Vault에는 켜두는 편이 맞습니다. 관련 내용은 Key Vault 시크릿 관리 글에 정리했습니다.
백업 비용이 예상보다 큰 이유
백업을 켜고 몇 달 뒤 청구서를 보면 생각보다 큰 경우가 있습니다. 세 가지 요인이 겹칩니다.
- 보호된 인스턴스 요금 — VM 1대당 고정 요금이 붙습니다. 백업 용량과 무관합니다
- 백업 스토리지 용량 — 여기서 GRS(지역 중복)는 LRS의 약 2배입니다
- 보관 기간 — 연 단위 보관을 7년으로 잡으면 복구 지점이 계속 쌓입니다
두 번째가 판단이 필요한 지점입니다. GRS는 리전 전체가 날아가도 복구할 수 있게 해주지만, 비용이 두 배입니다. Tier 2 이하 시스템에는 LRS로 충분한 경우가 많습니다. 리전 장애까지 대비해야 하는 시스템이 실제로 몇 개인지 세어보시길 권합니다.
# 볼트별 백업 스토리지 사용량 확인
az backup vault list --query "[].{name:name, rg:resourceGroup, redundancy:properties.redundancySettings.standardTierStorageRedundancy}" -o table
# 백업 항목별 최근 복구 지점 크기 추이
az backup item list --vault-name "$VAULT" -g "$RG" \
--query "[].{item:properties.friendlyName, lastBackup:properties.lastBackupTime, status:properties.lastBackupStatus}" \
-o table중복 옵션은 볼트를 만든 뒤 백업 항목이 하나라도 등록되면 변경할 수 없습니다. 처음에 정해야 합니다. 나중에 바꾸려면 볼트를 새로 만들고 백업을 다시 시작해야 하는데, 그러면 기존 복구 지점을 잃습니다.
백업 실패를 모르고 지나가지 않으려면
실무에서 가장 위험한 상황은 백업이 몇 주째 실패하고 있는데 아무도 모르는 것입니다. 포털에 들어가야만 보이는 상태로 두면 반드시 놓칩니다.
// Log Analytics - 지난 7일 백업 실패 항목
AddonAzureBackupJobs
| where TimeGenerated > ago(7d)
| where JobOperation == "Backup"
| summarize
Total = count(),
Failed = countif(JobStatus == "Failed"),
LastRun = max(TimeGenerated)
by BackupItemUniqueId
| where Failed > 0
| sort by Failed desc이 쿼리를 경고 규칙으로 걸어두세요. 심각도는 Sev 2 정도가 적당합니다. 새벽에 깨울 일은 아니지만 다음 근무일에는 반드시 봐야 하는 항목입니다. 알림 설계 기준은 Monitor 알림 설계 글에 정리했습니다.
흔한 백업 실패 원인 세 가지도 함께 알아두면 대응이 빠릅니다.
- VM이 할당 해제 상태 — 꺼진 VM은 백업이 실패하거나 크래시 일관성 스냅샷만 남습니다. 개발 VM 자동 종료와 백업 시각이 겹치면 자주 발생합니다
- 디스크가 백업 중 확장됨 — 백업 진행 중 디스크 크기를 바꾸면 실패합니다
- 확장(Extension) 오류 — VM 에이전트가 오래됐거나 응답하지 않는 경우. VM 안에서 에이전트 상태를 확인해야 합니다
첫 번째가 특히 흔합니다. 백업 시각을 자동 종료 시각보다 앞으로 옮기기만 해도 해결됩니다.
랜섬웨어 대비: 불변 볼트와 다단계 삭제
공격자가 침투하면 백업부터 지우려 합니다. 백업이 지워지면 몸값을 낼 수밖에 없기 때문입니다. Azure Backup에는 이를 막는 기능이 있고, 기본값이 아닌 것들이 있습니다.
- 소프트 삭제 — 백업을 지워도 14일간 보관. 기본 활성화되어 있습니다
- 다단계 인증(MUA) — 백업 삭제·정책 변경 같은 중요 작업에 별도 승인을 요구. 기본 비활성
- 불변 볼트(Immutable Vault) — 보관 기간 단축이나 삭제를 원천 차단. 기본 비활성
운영 환경이라면 불변 볼트를 켜는 것을 권합니다. 다만 켜면 보관 기간을 줄일 수 없게 되므로, 정책이 확정된 뒤에 적용하세요.
# 백업 항목의 소프트 삭제 상태 확인
az backup vault backup-properties show \
--name "$VAULT" -g "$RG" \
--query "{softDelete:softDeleteFeatureState, redundancy:storageModelType}" -o table정리
- 중단 1시간당 손실을 잡고 RPO·RTO를 역산한다 (감이 아니라 금액으로)
- 시스템을 3등급으로 나눈다. 개발 환경은 백업 대신 IaC 재생성
- 보관은 일·주·월·연 계층으로 구성한다 (스케줄은 UTC 주의)
- 분기 1회 별도 리소스 그룹에 복구 훈련을 하고 시간을 잰다
- VM 백업에 포함되지 않는 것들(DB·Blob·Key Vault·인프라 구성)을 별도로 챙긴다
- 운영 볼트에는 불변 볼트와 MUA를 켠다
백업의 목적은 백업을 남기는 게 아니라 복구에 성공하는 것입니다. 한 번도 복구해보지 않은 백업은 아직 백업이 아닙니다. 비용 측면은 Blob Storage 수명 주기 정책과 함께 보시면 보관 비용을 함께 최적화할 수 있습니다.