한눈에 보기
- ‘백업했으니 안심’이 아니라 RPO·RTO 기준으로 복구를 설계하는 법을 정리합니다.
- 핵심: 얼마나 잃어도 되나(RPO), 얼마나 빨리 살려야 하나(RTO)를 먼저 정한다.
- 보관 기간(LTR)과 복제 옵션이 비용을 좌우합니다.
백업의 진짜 목적은 ‘복구’입니다. 그런데 복구를 안 해보면 백업이 쓸모 있는지 알 수 없습니다. 먼저 목표부터 숫자로 정합시다.
먼저 RPO·RTO를 정한다
| 지표 | 의미 | 질문 |
|---|---|---|
| RPO | 허용 데이터 손실 | 몇 분/시간치까지 잃어도 되나? |
| RTO | 허용 복구 시간 | 몇 분/시간 안에 살려야 하나? |
RPO가 짧을수록 백업 주기를 촘촘히, RTO가 짧을수록 복구 자동화·이중화가 필요합니다. 이 두 숫자가 모든 선택의 기준이 됩니다.
Azure의 백업 수단
- Azure Backup(Recovery Services 자격 증명 모음) — VM·파일·DB 백업과 보관 정책.
- SQL 자동 백업 + LTR — 단기 PITR(특정 시점 복원) + 장기 보관.
- 스토리지 복제(LRS/ZRS/GRS) — 지역/리전 장애 대비 데이터 이중화.
# VM 백업 사용 설정(개념 예시)
az backup protection enable-for-vm -g <RG> \
--vault-name <VAULT> --vm <VM> --policy-name DefaultPolicy비용은 ‘보관’에서 갈린다
백업 비용의 핵심은 보관 기간과 복제 범위입니다. 장기 보관(LTR)을 길게, 복제를 지역 간(GRS)으로 둘수록 안전하지만 비싸집니다. 규정상 필요한 만큼만 보관하고, 중요도에 따라 차등하세요.
가장 중요한 것: 복구 리허설
백업은 ‘복구 테스트’를 해봐야 진짜입니다. 분기마다 한 번씩 실제 복원을 연습하면 RTO가 현실적인지, 절차에 빠진 게 없는지 드러납니다. 안 해본 백업은 백업이 아니라 ‘백업이라는 믿음’일 뿐입니다.
흔한 실수
- 복구 테스트를 한 번도 안 함 — 정작 필요할 때 복원이 실패합니다.
- 모든 걸 동일 정책으로 — 중요도별로 RPO·보관을 차등해야 비용·안전이 맞습니다.
- 같은 리전에만 보관 — 리전 장애 시 백업도 같이 잃을 수 있습니다(중요 데이터는 지역 간 복제).
자주 묻는 질문(FAQ)
- Q. RPO와 RTO 중 뭐가 먼저인가요? A. 둘 다 비즈니스 요건에서 나옵니다. ‘얼마 잃어도 되나(RPO)’와 ‘얼마나 빨리 살려야 하나(RTO)’를 함께 정하세요.
- Q. 백업 비용을 줄이려면? A. 보관 기간을 필요한 만큼만, 복제 범위를 중요도에 맞게 차등하세요.
- Q. 삭제·랜섬웨어 대비책은? A. 소프트 삭제·불변(immutable) 보관을 켜 백업 자체의 변조·삭제를 막으세요.
마치며
RPO·RTO를 숫자로 정하고, 중요도별로 보관·복제를 차등하고, 분기마다 복구를 리허설하세요. 복구해본 백업만이 진짜 백업입니다.