백업·복구·고가용성과 재해복구
백업 방식과 복구 검증, 복제·클러스터·페일오버, RPO·RTO·DR·BCP를 학습한다.
1. 백업의 목적
백업은 원본 데이터가 삭제·손상·암호화·오염되었을 때 이전의 신뢰 가능한 상태로 복구하기 위한 별도 사본이다.
운영 원본
│
├─ 장애·실수·랜섬웨어·논리오류
▼
백업 사본 ─ 검증된 복구 절차 ─► 복원 환경
RAID·복제·클러스터는 가용성을 높이지만 논리적 삭제와 악성 변경도 복제할 수 있어 백업을 대신하지 않는다.
2. 백업 방식
| 방식 | 백업 대상 | 복구 시 필요 | 특징 |
|---|---|---|---|
| 전체 | 전체 데이터 | 마지막 전체 | 백업 크기 큼, 복구 단순 |
| 증분 | 직전 어떤 백업 이후 변경 | 전체 + 이후 모든 증분 | 백업 빠름, 복구 단계 많음 |
| 차등 | 마지막 전체 이후 변경 | 전체 + 마지막 차등 | 증분보다 백업 증가, 복구 단순 |
| 로그 | 변경 로그 | 기준 백업 + 로그 연속 | 시점 복구 가능 |
| 스냅샷 | 특정 시점의 저장상태 | 스냅샷·원본 구조 | 빠르지만 별도 복제 여부 확인 |
월: 전체 F
화: 증분 I1
수: 증분 I2
목: 증분 I3
목요일 복구 = F + I1 + I2 + I3
차등 방식이라면 목요일 복구는 전체 백업과 목요일 차등 백업이 필요하다.
3. 3-2-1 원칙과 격리
일반적인 백업 설계 원칙:
데이터 사본 3개
서로 다른 매체·저장방식 2개
원격·오프사이트 사본 1개
현대 위협에는 다음도 중요하다.
- 불변(Immutable) 백업
- 오프라인·논리적 격리
- 백업 관리자 권한 분리
- 백업 데이터 암호화
- 키·자격증명 분리
- 랜섬웨어 감염 전 시점 보존
- 삭제·보존 정책의 이중 승인
4. 백업 성공과 복구 가능성
백업 작업의 성공 로그만으로 복구 가능성을 증명하지 못한다.
백업 생성
↓
무결성 검사
↓
별도 환경 복원
↓
애플리케이션 기동
↓
데이터 건수·업무 결과 대사
↓
RTO·RPO 충족 확인
복구 훈련에는 문서, 권한, 네트워크, 키, 외부 연계, 담당자의 실제 수행 가능성을 포함한다.
5. RPO와 RTO
- RPO(Recovery Point Objective): 허용 가능한 데이터 손실 시점
- RTO(Recovery Time Objective): 허용 가능한 서비스 복구 시간
시간 ─────────────────────────────────►
마지막 복구 가능 시점 장애 발생 서비스 복구
│<── RPO ──>│<────── RTO ──────>│
예: RPO 15분이면 장애 시 최대 15분가량의 변경 손실을 허용한다는 의미이다. RTO 2시간이면 장애 발생 후 2시간 안에 목표 수준으로 서비스를 복구해야 한다.
6. 고가용성
고가용성은 계획·비계획 중단을 줄여 서비스를 지속 제공하는 능력이다.
가용률:
가용률 = 정상 서비스 시간 / 전체 대상 시간 × 100
30일 기준 99.9% 가용률의 허용 중단시간은 대략 다음과 같다.
30일 × 24시간 × 60분 × 0.001 ≈ 43.2분
측정 범위, 제외되는 계획 정지, 부분 장애 판단 기준을 SLA에서 명확히 해야 한다.
7. 이중화 방식
Active-Standby
사용자 → Active
│ 상태·데이터 동기화
Standby
장애 시 Standby가 승격
단순하지만 대기 자원이 평소 충분히 사용되지 않을 수 있고 승격시간이 필요하다.
Active-Active
┌─► Active A
사용자 ──┤
└─► Active B
자원을 함께 사용하고 장애 시 나머지가 처리하지만 데이터 일관성, 세션, 부하, split-brain 방지가 복잡하다.
8. 클러스터와 페일오버
클러스터는 여러 노드가 하나의 서비스처럼 동작하도록 구성한다.
헬스체크·쿼럼
│
┌───┴──────────┐
Node A Node B
Active Standby
│ 공유·복제 데이터
└──────┬────┘
Storage
- 헬스체크
- 장애 감지
- 리더·활성 노드 결정
- 페일오버
- 데이터 무결성
- fencing·split-brain 방지
- 복구 후 failback 정책
split-brain은 서로 단절된 노드가 모두 자신을 활성으로 판단해 데이터 충돌을 일으키는 상황이다.
9. 복제
| 방식 | 장점 | 비용·위험 |
|---|---|---|
| 동기 복제 | 데이터 손실을 줄임 | 원격 지연이 쓰기 성능·가용성에 영향 |
| 비동기 복제 | 지연과 거리 대응 | 장애 직전 미전송 데이터 손실 가능 |
| 논리 복제 | 일부 객체·변경 전달 | 변환·순서·충돌 관리 |
| 물리 복제 | 저장 단위 복제 | 플랫폼·구조 제약 |
복제 지연을 모니터링하지 않으면 대기 시스템이 오래된 데이터를 가진 상태로 승격될 수 있다.
10. DR과 BCP
- DR: 재해 시 IT 시스템·데이터를 복구하는 계획
- BCP: 핵심 업무를 허용 수준으로 지속·재개하는 더 넓은 계획
업무 영향 분석
↓
핵심 업무·복구 우선순위
↓
RTO·RPO 결정
↓
대체 인력·장소·통신·IT 전략
↓
문서·교육·훈련
↓
정기 시험·개선
DR 센터 유형은 조직마다 명칭과 구현이 다르지만 즉시성에 따라 cold, warm, hot site 개념으로 구분할 수 있다.
- Cold: 공간·기본 설비 중심, 복구시간 김
- Warm: 일부 장비·데이터 준비
- Hot: 운영과 유사한 환경·데이터를 상시 준비
11. 재해복구 훈련
훈련 유형:
- 문서 검토
- Tabletop 시나리오
- 부분 기술 복구
- 대체센터 전환
- 실제 업무 포함 종합훈련
검증 항목:
- 연락망과 의사결정
- 백업·키·계정 접근
- 네트워크·DNS 전환
- 데이터 정합성
- 외부 기관·업체 연계
- 사용자 공지
- 원센터 복귀
12. 백업 체인과 복원 계산
월: Full F0
화: Incremental I1
수: Incremental I2
목: Incremental I3
목요일 상태 복원에는 F0+I1+I2+I3이 필요하다. 차등 백업이면 F0+목요일 차등 D3만 필요하지만 D3 크기는 시간이 갈수록 커진다.
- 3-2-1: 데이터 3개, 서로 다른 매체 2종, 오프사이트 1개
- 3-2-1-1-0: 여기에 offline/immutable 1개와 복원 검증 오류 0을 목표로 추가
- 백업 성공 로그보다 실제 복원·checksum·응용 일관성 검증이 중요
13. RPO·RTO와 BIA
장애 발생 15:00
마지막 복구 가능 시점 14:45 → 실제 데이터 손실 15분
서비스 재개 16:30 → 실제 복구시간 90분
RPO는 허용 데이터 손실 시점, RTO는 허용 서비스 중단시간이다. BIA는 업무별 최대 허용 중단, 의존 인력·장소·공급자·데이터와 복구 우선순위를 정한다.
14. HA 쿼럼과 fencing
2노드가 네트워크 분할에서 모두 쓰기를 받으면 split brain이 된다. 홀수 투표 노드, witness, quorum과 fencing(STONITH 등)으로 한쪽의 자원 접근을 차단한다.
5표 클러스터의 과반수 = floor(5/2)+1 = 3표
단순 heartbeat 손실만으로 상대가 완전히 죽었다고 단정하지 않고, 저장소·네트워크 경로를 포함한 격리 절차를 수행한다.
15. 복제와 일관성
동기 복제는 데이터 손실을 줄이지만 지연·가용성에 영향을 주고, 비동기 복제는 원격 성능에 유리하지만 lag만큼 데이터 손실 가능성이 있다. 읽기 replica는 replication lag 때문에 read-after-write가 깨질 수 있다.
16. DR 훈련 수준
문서 검토 → tabletop → 부분 기술 복구 → 병행 운영 → 실제 전환·복귀 순으로 위험과 검증 강도가 커진다. 복구뿐 아니라 DNS·인증·비밀·외부연계·배치·데이터 정합성과 원센터 복귀까지 검증한다.
확인 문제
- 목요일 증분 복원에 필요한 체인은?
- 장애 15:00, 복구시점 14:45면 실제 데이터 손실은?
- 5표 클러스터의 과반수 쿼럼은?
- fencing이 필요한 이유는?
- 비동기 복제의 대표 RPO 위험은?