복구 성공률 중심 백업 운영 2026

왜 복구 성공률인가

#

많은 팀이 백업 잡의 초록 불만 보고 안심합니다. 그러나 실제 사고에서는 암호화 키 누락, 스냅샷만 있고 메타데이터가 없음, 복원 경로가 다른 OS 버전을 가정함 같은 이유로 복구 단계에서 막히는 경우가 훨씬 많습니다. 따라서 운영의 중심축은 “어제 백업이 돌았는가”가 아니라 **“정해진 시간 안에 검증된 절차로 서비스를 되살릴 수 있는가”**여야 합니다. 홈랩과 소규모 프로덕션 모두에서 비용 대비 효과가 가장 큰 지점이기도 합니다.

RPO·RTO를 먼저 고정하기

#

복구 설계는 감이 아니라 두 숫자로 시작합니다. **RPO(허용 데이터 손실 시간)**는 “최악의 경우 몇 시간 전까지 되돌아가도 되는가”이고, **RTO(복구 목표 시간)**는 “중단 후 몇 시간 안에 다시 써야 하는가”입니다. NAS 한 대만 지킨다면 RPO 24시간·RTO 4시간처럼 현실적으로 잡고, 그에 맞춰 전체·증분·스냅샷·오프사이트 중 무엇을 쓸지 결정합니다. 숫자가 없으면 장비만 늘어나고 검증은 계속 미뤄집니다.

리허설이 유일한 진짜 검증

#

월 1회 이상 부분 복구(파일 몇 개, DB 한 테이블, VM 한 대)와 분기 1회 시나리오 복구(“이 NAS가 통째로 사라졌다” 가정)를 돌립니다. 성공 기준은 다음을 모두 만족할 때입니다: (1) 체크리스트대로 시간 내 완료, (2) 애플리케이션이 기동 후 스모크 테스트 통과, (3) 담당자가 문서 없이도 같은 절차를 재현 가능. 실패하면 백업 정책이 아니라 복구 런북을 먼저 고칩니다.

3-2-1과 불변성의 실무 적용

#

규칙 3-2-1(원본 외 2매체, 그중 1은 오프사이트)은 그대로 두되, 랜섬웨어 대비를 위해 한 사본은 쓰기 불가·버킷 잠금·WORM 등으로 “지우기 어렵게” 만듭니다. 홈랩이라면 클라우드 한 버킷에 객체 잠금을 켜거나, 주간 풀 백업만 USB에 분리 보관하는 식으로도 의미가 있습니다. 중요한 것은 “공격자가 백업까지 지울 수 있는 단일 계정”을 없애는 것입니다.

운영 지표 예시

#

flowchart LR
  A[RPO/RTO 확정] --> B[백업 설계 3-2-1]
  B --> C[자동 백업]
  C --> D[무결성 검사]
  D --> E[월간 부분 복구]
  E --> F[분기 풀 시나리오]
  F --> G[런북·키 회전 반영]
  G --> B

실전 시나리오

#

스냅샷은 매일 쌓이는데 공유 폴더 ACL이 빠진 채 복원되어 접근이 막힌 사례가 있습니다. 해결은 복구 대상에 권한·서비스 계정·인증서를 명시하고, 리허설 때마다 해당 항목을 체크리스트에 넣는 것입니다. 백업 소프트웨어의 “성공” 한 줄보다 복원 후 로그인까지의 한 사이클이 훨씬 신뢰할 만한 신호입니다.

체크리스트

#

• RPO·RTO가 문서 첫머리에 숫자로 적혀 있는가
• 복구에 필요한 비밀·키가 백업과 분리 보관되는가
• 최소 한 사본이 삭제·암호화 공격에 견디는가
• 담당자 교체 시에도 리허설을 이어갈 수 있는가

마무리

#

복구 성공률 중심으로 보면 장비와 라이선스보다 리허설 캘린더와 런북 품질이 먼저입니다. 백업은 비용이고, 복구 연습은 보험금을 실제로 타는 행위에 가깝습니다. 이 리듬만 지켜도 “백업은 있는데 살릴 수 없었다” 클래스의 사고를 크게 줄일 수 있습니다.