증분과 차등, 어떤 백업이 유리할까?

1. 실무에서 가장 자주 듣는 질문

“증분 백업과 차등 백업 중 뭐가 더 좋은 건가요?”

백업을 설계하거나 운영하는 실무자라면, 누구나 한 번쯤 이런 질문을 받는다.
둘 다 전체 백업 이후의 데이터 변화만 백업한다는 점에서 비슷해 보이지만,
복원이라는 관점에서 보면 전혀 다른 전략이 된다.

많은 경우, 저장 효율성과 속도만 비교해서 증분 백업이 '가볍고 효율적이다'는 이유로 선택된다.
하지만 진짜 중요한 건 복원 시나리오에서 어떤 방식이 더 신뢰성과 속도를 보장하느냐이다.

월요일에 전체 백업을 진행한 뒤, 화~금까지 데이터를 백업하는 상황을 가정하자.

증분 백업
- 월요일: 변경된 a만 백업
- 화요일: 변경된 b만 백업
- 수요일: 변경된 c만 백업
  → 복원 시: 전체 백업 + a + b + c = 총 4단계 필요
  → 중간 단계 하나라도 깨지면 복원이 실패할 수 있음
차등 백업
- 월요일: a 백업
- 수요일: a + b + c 백업
- 금요일: a + b + c + d + e 백업
  → 복원 시: 전체 백업 + 마지막 차등 백업(a+b+c)만 있으면 복원 가능
  → 복원 절차 단순, 리스크 낮음

이 차이는 실제 장애 상황에서 큰 차이를 만든다.
백업 속도보다 복원 시간과 복원 신뢰도가 더 중요하다면, 차등 백업이 우위에 있다.

백업은 복원을 위해 존재한다.
따라서 복원 시 얼마나 빠르고 정확하게 데이터를 되살릴 수 있느냐가 핵심 기준이 되어야 한다.

RTO (Recovery Time Objective):
복구에 걸리는 시간. 시스템이 중단된 후 서비스가 복원되기까지 걸리는 시간의 목표
→ 차등 백업은 복원 시간이 짧아 RTO 만족에 유리
RPO (Recovery Point Objective):
복구 가능한 시점. 데이터 손실을 감수할 수 있는 시간 범위
→ 증분 백업은 더 세밀한 주기 설정이 가능해 RPO에 유리

증분 백업만 설정해두고 복구 테스트를 안 해본 경우
→ 실제 복원 시 증분 백업 일부가 손상되거나 누락되어 전체 복구 실패
→ 해결: 주기적인 복구 테스트 필수
복원 시나리오 없이 백업 스케줄만 설정한 경우
→ 정작 시스템이 멈췄을 때, 어떤 백업으로 복원해야 하는지 몰라 혼란 발생
→ 해결: 백업 유형별 복원 시나리오 문서화 필수
백업은 되는데 저장소가 부족해 오래된 증분이 지워지는 경우
→ 복원 불가능한 백업 데이터만 남게 됨
→ 해결: 백업 유지 정책, 디스크 용량, 백업 순환 정책 수립 필요

어떤 백업 방식이 더 좋다고 단정할 수는 없다.
시스템의 특성과 목표, 복원 시나리오에 따라 최적의 전략은 달라진다.

백업은 눈에 보이지 않지만,
서비스와 시스템의 생명줄이다.
복원이 되지 않는 백업은, 존재하지 않는 백업과 같다.