"매일 전체 백업을 받으면 안전하지 않나요?" 맞는 말이지만, 데이터가 수백 GB가 되면 매일 전부 복사하는 건 시간도 저장 공간도 감당이 안 됩니다. 그래서 백업은 전체·증분·차등 세 가지로 나뉩니다. 세 방식의 차이는 단 하나, "직전 무엇을 기준으로 바뀐 것만 담느냐" 입니다. 이 기준만 잡으면 복구 절차까지 자연스럽게 따라옵니다.
세 가지 백업 한눈에
| 종류 | 무엇을 담나 | 백업 크기 | 복구 속도 |
|---|---|---|---|
| 전체(Full) | 전체 데이터 통째로 | 가장 큼 | 가장 빠름(1개만 복원) |
| 증분(Incremental) | 직전 백업 이후 바뀐 것 | 가장 작음 | 가장 느림(전체+증분 전부) |
| 차등(Differential) | 마지막 전체 이후 바뀐 것 | 중간 | 중간(전체+차등 1개) |
핵심은 증분은 "바로 직전 백업"을, 차등은 "마지막 전체 백업"을 기준으로 삼는다는 점입니다. 이 기준 차이가 크기와 복구 방식을 전부 결정합니다.
일주일 시나리오로 비교하기
일요일에 전체 백업을 받고 월요일부터 데이터가 매일 조금씩 바뀐다고 가정해 봅니다.
TEXT
증분 방식
일(전체) → 월(일 대비 변경) → 화(월 대비) → 수(화 대비) ...
차등 방식
일(전체) → 월(일 대비 변경) → 화(일 대비) → 수(일 대비) ...
수요일에 장애가 나서 복구한다면 이렇게 달라집니다. 증분은 일요일 전체 + 월 + 화 + 수를 순서대로 모두 적용해야 합니다. 백업 파일 중 하나라도 손상되면 그 뒤가 전부 깨집니다. 반면 차등은 일요일 전체 + 수요일 차등 단 2개면 끝납니다. 대신 차등은 시간이 갈수록 마지막 전체 이후 누적 변경을 계속 담으므로 파일이 점점 커집니다.
무엇을 고를까
- 저장 공간·백업 시간이 빠듯하다 → 증분. 매일 담는 양이 가장 적습니다.
- 복구 속도와 단순함이 중요하다 → 차등. 전체 1개와 차등 1개만 있으면 됩니다.
- 데이터가 작거나 복구 실수를 줄이고 싶다 → 전체. 의존 관계가 없어 가장 안전합니다.
실무에서는 보통 섞어 씁니다. 주 1회 전체, 매일 증분(혹은 차등)을 받는 식입니다. 어떤 조합이든 복구를 실제로 한 번 해보는 리허설이 빠지면 백업은 의미가 없습니다. 받아만 두고 복원해 본 적 없는 백업이 정작 장애 때 안 풀리는 일이 가장 흔한 사고입니다.
요점 정리
- 세 백업의 차이는 기준점 하나 — 전체는 통째로, 증분은 직전 대비, 차등은 마지막 전체 대비.
- 증분은 작지만 복구 시 백업 사슬 전체가 필요하고, 차등은 크지만 전체+차등 2개로 복구된다.
- 백업은 복구 리허설까지 해야 완성된다.
pg_dump로 전체 백업을 받고 변경분만 따로 보존하며 복원까지 직접 해보는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.