[클라우드 백업·복구 실전 시리즈] 전체 가이드 (중소규모 기준)

• (1) 파일 단위 백업

• (2) 스냅샷

• (3) 이미지/시스템 백업(또는 IaC로 재구성).

• 3(사본 3개): 운영 원본 + 백업 2개(서로 다른 저장소/정책)

• 2(매체 2개): 오브젝트 스토리지 + 별도 계정/리전/온프레(또는 다른 벤더)

• 1(오프사이트 1개): 운영 계정/권한/네트워크와 분리된 위치(“로그인 가능한 곳”이 아니라 “격리된 곳”)

• ① 백업 설계가 “저장 비용 최소화”에만 맞춰지면 복구 단계가 복잡해지고 실패율이 올라간다.

• ② 계정·권한·암호화 키가 단일 지점에 묶이면, 장애가 아니라도 사람 변경만으로 복구가 막힌다.

• ③ 백업 보관 기간만 정하고 “어떤 상황에서 무엇을 먼저 복구할지”가 없으면 복구 순서가 매번 흔들린다.

• ④ 스냅샷과 파일 백업은 복구 속도와 범위가 다르지만, 이를 구분하지 않으면 RTO를 지키기 어렵다.

• ⑤ 검증(restore test)을 자동화하지 않으면 백업은 조용히 깨지고, 깨진 사실은 복구 시점에야 드러난다.

• ⑥ 랜섬웨어·내부 실수는 “삭제/변조” 형태로 들어오므로, 변경 불가(immutable)나 별도 계정 격리가 없으면 사본도 같이 망가진다.

1. 실수(삭제/덮어쓰기) 시나리오 : 파일/폴더 단위 복구 → 권한/공유 설정 복원 → 사용자 확인

2. 서버 장애(부팅 불가) 시나리오 : 스냅샷 롤백 또는 새 인스턴스 재생성 → 애플리케이션 설정 주입 → 서비스 헬스체크

3. 보안 사고(랜섬웨어/계정 탈취) 시나리오 : 격리 계정에서 불변 사본 확인 → 클린 환경에 복구 → 침해 범위 확정 후 재연결

1. 기준 숫자 확정 : 핵심 서비스별 RPO(예: 24시간) / RTO(예: 4시간) / 보관 기간(예: 30일) / 월간 복구 테스트 1회

2. 격리와 권한 분리 : 운영 계정과 다른 계정(또는 최소 다른 권한 경계)에 백업 저장소를 두고, 삭제 권한은 최소 2인 승인(또는 별도 롤)으로 제한
2-보강) 2인 승인 체계를 시스템으로 강제할 수 없으면 삭제 권한 별도 계정 + MFA(다중 인증) + 로그 감사(감사 로그 보존) 3가지를 동시에 적용한다.

3. 복구 자동 검증 : “백업 성공”이 아니라 “복구 성공”을 통과 조건으로 바꾸고, 샘플 데이터 복원(무결성 체크)까지 자동/반자동으로 연결

구현 예시(벤더 비의존, 3줄 템플릿):

• 오브젝트 스토리지: 버전 관리 + 삭제 보호(불변 기간 14일)

• 스냅샷: 핵심 서버 일 1회 + 변경 전 수동 1회

• 계정 분리: 운영 계정과 다른 백업 계정에 저장, 삭제 권한 분리

• 10분: 백업 잡/스냅샷 실패 알림 확인(지난 30일), 실패 0건 목표

• 10분: 불변/버전 보관 정책 확인(보관 기간, 삭제 정책, 계정 분리 상태)

• 10분: 샘플 복구 1회 실행(가장 중요한 데이터 1개), 결과를 기록(성공/실패, 소요 시간, 막힌 단계)

– 30초 체크리스트

• 핵심 서비스 1개에 대해 RPO(시간)와 RTO(시간)를 숫자로 적어뒀다.

• 운영 계정과 분리된 저장소(계정/권한/리전 중 최소 1개)를 사용한다.

• 삭제/변경 불가(immutable) 또는 버전 보관이 켜져 있다.

• 월 1회 샘플 복구를 하고, 소요 시간(분)을 기록한다.

• 복구 절차 문서(플레이북)에 담당자 2명 이상이 접근 가능하다.

• “백업 성공” 알림만 보고 안심 : 알림은 저장 성공일 뿐, 복구 성공이 아니다(복구 테스트가 없으면 0점).

• 키/권한 단일화 : 암호화 키, 루트 권한, 백업 저장소 삭제 권한이 한 사람·한 계정에 몰리면 사고 때 복구가 막힌다.

• 스냅샷만 믿기 : 스냅샷은 빠르지만 격리/장기보관이 약해, 계정 침해나 정책 변경에 같이 날아갈 수 있다.

• 복구 순서 미정 : “DB→인증→앱→파일”처럼 의존성을 못 박지 않으면 RTO가 매번 늘어난다.
  • 의존성 예시 1줄: 인증(IdP) → DB → 애플리케이션 → 파일/오브젝트 → 배치/리포트 순으로 복구한다.

• 비용 최적화를 먼저 함 : 비용은 2순위다. 먼저 복구가 되고, 그 다음에 보관 주기/계층화를 조정한다.

• “가장 중요한 데이터 1개”를 복구 훈련 데이터로 고정하고, 매달 같은 절차로 반복한다.

• 백업 저장소는 운영망과 분리하고, 백업 읽기 전용 계정을 따로 둔다.

• 변경이 큰 달(권한 개편/도메인 이전/마이그레이션)은 복구 테스트를 추가 1회로 규칙화한다.

• 백업 보관 기간(예: 30일)과 불변 기간(예: 14일)을 분리해 운영하면 사고 대응이 쉬워진다.

• 플레이북에 “연락 순서(1→2→3)”와 “결정권자”를 적어두면 장애 시 커뮤니케이션 비용이 줄어든다.

• 인력 1~2명, IT 전담 없음 : 파일 백업 + 버전/불변(가능 범위) + 월 1회 샘플 복구(가장 중요한 데이터 1개)부터 시작한다.

• 서버 3대 이상, 서비스 중단 민감 : 핵심 서버 스냅샷(짧은 RTO) + 오브젝트 장기 보관(격리) 조합으로 “빠른 복구 + 안전한 사본”을 분리한다.

• 보안 사고가 우려됨 : 운영 계정과 다른 계정/권한 경계에 불변 사본을 두고, 보안 사고 플레이북(격리→클린 복구→재연결)을 먼저 완주한다.

• 백업의 목표는 저장이 아니라 “정해진 시간 안에 복구 성공”이다.

• 3-2-1은 계정/권한/위치를 분리해 사본을 “격리”하는 규칙으로 적용한다.

• 월 1회 샘플 복구와 수치 기준(RPO/RTO)이 운영을 자동으로 단단하게 만든다.