인사이트리포트

들어가며

데이터베이스 백업은 인프라 관리의 핵심이자 장애 복구의 최후 보루이다. 그러나 많은 운영 현장에서 “Gzip으로 압축하고, 전체 백업만 돌린다”는 관행이 검증 없이 이어지고 있다.

이러한 레거시 관행이 초래하는 숨은 비용(TCO)은 막대하다. 잘못된 알고리즘 선택은 CPU를 한계까지 밀어붙이면서도 기대 이하의 처리량을 낸다. 압축 위치를 잘못 고르면 아무리 좋은 알고리즘을 써도 대역폭 제한 환경에서는 효과가 사라진다. 증분 백업 없이 전체 백업만 고집하면 스토리지와 네트워크 비용이 누적되고, RTO를 보장하기 어려워진다.

이 아티클은 네 가지 핵심 질문에 실측 데이터로 답한다.

●  압축 알고리즘과 수행 위치가 백업 성능에 미치는 영향은 얼마나 큰가?

●  대역폭 제한 환경에서 서버 사이드 압축이 왜 결정적으로 유리한가?

●  PG17 증분 백업과 압축을 결합하면 전송량이 얼마나 줄어드는가?

●  PG18 비동기 I/O(AIO)와 Clone이 복구 단계를 어떻게 바꾸는가?

단순히 신기능의 존재를 아는 것을 넘어, 운영 환경의 제약(대역폭, I/O)에 맞춰 최적의 파이프라인을 설계하는 것이 엔지니어의 진짜 역할이다. 본 아티클은 실측 데이터를 통해 그 명확한 기준을 제시한다.

압축 알고리즘 및 수행 위치에 따른 성능 비교

알고리즘보다 위치를 먼저 결정하라

pg_basebackup은 두 가지 압축 수행 위치를 지원한다. 위치 선택은 단순한 CPU 배치의 문제가 아니다.
–max-rate 속도 제한의 적용 기준이 위치에 따라 달라지기 때문에, 대역폭 제한 환경에서는 위치 선택이 성능을 좌우한다. 이 내용은 “대역폭 제한 환경에서의 압축 효율성 검증” 섹션에서 상세히 다룬다.

※ server-* / client-* 접두사를 명시하지 않으면 PG15 이상에서는 서버 사이드로 동작한다.

알고리즘 선택 기준

※ pg_basebackup의 –compress 기본값은 none(압축 없음)이다.

테스트

• 목적: Gzip의 한계를 정량 확인하고, 최적 속도(LZ4)와 최적 압축률(Zstd) 설정값을 검증한다.
• 환경: Rocky Linux 8.10 / PostgreSQL 17.9 / 8core / 16GB RAM / 98GB 데이터셋 / 3회 반복, 중앙값 채택

* Plain(-Fp) 대비 Tar(-Ft)의 약 10초 차이는 Tar 직렬화 오버헤드에서 기인한다.
★ 8코어 환경 기준 최적값. workers의 실질적 최적값은 코어 수와 I/O 환경에 따라 달라진다.

인사이트

Gzip은 이제 놓아주어라.

98GB 백업 기준 Gzip은 CPU 99.9%를 12분간 점유했다. server-zstd:workers=4는 더 낮은 CPU(94.5%)로 69초 만에 완료한다. 같은 하드웨어에서 10.5배 차이다.

속도 vs 압축률은 환경이 결정한다.

LZ4(76초, 10.64GB)와 Zstd(69초, 4.38GB) 모두 1분대다. 차이는 최종 크기 2.4배. 스토리지 비용이 중요하면 Zstd, 단순 고속 백업이 목적이면 LZ4를 선택한다.

workers 최적값은 환경마다 다르다.

본 테스트(8코어)에서는 workers=4가 최적이었다. workers=4 이후 성능 향상은 없었고, workers=16에서는 오히려 소폭 역전됐다. OS와 PG 프로세스가 쓸 코어가 줄어들면서 생기는 컨텍스트 스위칭 오버헤드가 원인이다. 일반적으로 “전체 코어 수의 절반” 수준을 시작점으로 삼고, 자체 환경에서 반드시 측정해 최적값을 찾는 것을 권장한다.

대역폭 제한 환경에서의 압축 효율성 검증 (–max-rate)

–max-rate의 결정적 특성: 적용 기준이 위치에 따라 달라진다

pg_basebackup의 –max-rate 옵션은 운영 네트워크 대역폭을 보호하기 위한 전송 속도 제한 기능이다. 이 옵션은 압축 수행 위치에 따라 속도 제한의 기준이 달라지는 결정적 특성을 갖는다. “압축 알고리즘 및 수행 위치에 따른 성능 비교” 섹션에서 위치 선택을 강조한 핵심 이유가 바로 여기에 있다.

–max-rate=50M을 적용했을 때, server-zstd는 압축 후 기준으로 50MB/s가 제한된다. 압축률이 22:1이라면 원본 기준 1,100MB/s 상당의 데이터를 동일한 제한 안에서 전송할 수 있다. client-zstd는 원본 기준으로 50MB/s가 제한되므로 유효 전송 효율이 극적으로 낮아진다.

테스트

• 목적: 대역폭 제한 환경에서 가장 빠르게 백업을 완료할 수 있는 최적 설정을 찾는다.
• 고정 조건: –max-rate=50M 공통 적용

★ 앞선 섹션과 동일하게 8코어 환경 기준 최적값이며, workers 수는 자체 환경에서 측정을 권장한다.

인사이트

client-zstd가 실패하는 이유.

–max-rate는 네트워크에 실제로 올라가는 데이터 기준으로 속도를 제한한다. client-zstd는 원본 98GB를 네트워크로 그대로 전송하므로 압축 없음과 동일한 2,001초가 소요된다. 아무리 좋은 알고리즘이라도 위치가 잘못되면 효과가 없다.

server-zstd:workers=4가 19.6배 빠른 이유.

서버에서 먼저 4.38GB로 압축한 뒤 전송하므로 동일한 50MB/s 제한 안에서 실질 전송량이 22배 줄어든다. 이는 앞선 섹션에서 확인한 server-side 압축의 이점이 –max-rate 환경에서 더욱 극대화된 결과다. 대역폭 제한이 필요한 운영 환경에서 서버 사이드 압축은 선택이 아닌 필수다.

PG17 증분 백업과 압축의 시너지: 전송량 99% 감소의 비밀

결과부터 본다: 11.13GB → 0.11GB

전체 DB(11.13GB) 대비 5% 데이터를 변경한 뒤 증분 백업과 압축을 결합했을 때, 최종 백업 크기가 0.11GB로 줄었다. 전체 백업의 약 1%에 해당하는 수치다. 이 극적인 감소가 어떻게 가능한지, 내부 메커니즘을 순서대로 살펴본다.

• 환경: Rocky Linux 8.10 / PostgreSQL 17.9 / pgbench scale 700(10GB) + change_target 테이블(475MB)

★ 8코어 환경 기준 최적값. workers 수는 자체 환경에서 측정을 권장한다.

메커니즘 1: WAL Summarizer 기반 블록 레벨 변경 추적

PG16까지 PostgreSQL은 네이티브 증분 백업을 공식 지원하지 않았다. 운영 현장에서는 pgBackRest, Barman 같은 서드파티 도구로 증분 백업을 구현해 왔다. PG17에서 pg_basebackup이 –incremental 옵션을 공식 지원하면서, 외부 도구 없이 네이티브 증분 백업이 가능해졌다.

    1. PG17 증분 백업은 WAL summarizer 기반의 블록 레벨 변경 추적으로 동작한다.

2.  전체 백업 수행 시 backup_manifest 파일이 생성된다. 각 데이터 블록의 체크섬과 LSN(Log Sequence Number)이 기록된다.

3.  증분 백업 수행 시 –incremental <manifest_path> 옵션으로 이전 매니페스트를 참조하고, 변경된 블록만 선택적으로 백업한다.

4. 전송량과 저장 용량이 변경률에 비례해 줄어든다.

메커니즘 2: Tar + zstd 조합에서 압축 시너지가 극대화되는 이유

증분 백업은 Plain과 Tar 두 가지 포맷을 지원하며, 포맷에 따라 압축 적용 방식이 달라진다.

Plain 포맷은 변경된 블록 파일을 개별 저장하는 구조상 스트림 압축이 제한적이다.
반면 Tar 포맷은 전체 스트림을 zstd로 압축하므로 0.32GB → 0.11GB의 추가 최적화가 가능하다.

복구를 위한 병합: pg_combinebackup

증분 백업은 단독으로 복구할 수 없다. 전체 백업과 증분 백업 체인을 반드시 병합해야 복구 가능한 상태가 되며, 이 역할을 pg_combinebackup이 수행한다.

※ 권장 운영 패턴: 일요일 전체 백업 → 월~토 증분 백업 × 6회 → 다음 일요일 체인 리셋.
변경률이 높은 환경(10% 이상)에서는 체인 길이를 줄이고 전체 백업 주기를 단축하는 것이 병합 비용 관리에 유리하다.

인사이트

증분 백업 단독으로 이미 97%가 줄었다.

압축 없이도 11.13GB → 0.32GB, 전송량 35배 감소. 매일 전체 백업을 수행하는 환경이라면 증분 백업 도입만으로도 네트워크 부하·스토리지 비용이 극적으로 감소한다.

압축을 더하면 전체 백업의 1%만 전송한다.

증분 + zstd 조합은 0.11GB, 전체 백업 대비 99% 감소·101배 절감. 증분이 변경 블록을 걸러내고, zstd가 그 위에서 추가로 압축하는 이중 최적화 효과다.

Tar 포맷이 실질적 선택지다.

Plain·Tar의 증분 크기는 동일하지만, 스트림 압축은 Tar에서만 완전히 동작한다. pg_combinebackup 병합 편의성까지 고려하면 Tar + zstd 조합이 권장 설정이다.

PG18 AIO가 백업 파이프라인에 가져온 변화

PG18 비동기 I/O: 백업 생성보다 복구가 달라진다

PG18 AIO의 효과는 백업 생성보다 복구(restore) 및 병합(pg_combinebackup) 단계에서 더 크게 나타난다.

기존 동기 I/O에서는 pg_combinebackup이 전체 백업 블록을 읽고, 증분 블록과 병합하고, 결과를 쓰는 과정이 직렬화 된다. 읽기가 완료되어야 쓰기가 시작되는 구조다. AIO에서는 읽기와 쓰기가 겹쳐 실행되며, 특히 압축된 증분 백업 병합 시 압축 해제 → 블록 병합 → 결과 쓰기의 각 단계가 파이프라인화 되어 효과가 극대화된다.

PG18 AIO 활성화 방법 및 유의점

PG18에서 지원하는 io_method 옵션은 세 가지다.

※ io_uring 적용 체크리스트 (예시)

PG18 Clone: 병합 없는 복구

PG18에서는 pg_combinebackup 병합 없이 복구할 수 있는 Clone 방식이 도입됐다. Clone 기반 복구는 파일시스템 계층의 Copy-on-Write(CoW) 기능에 전적으로 의존하므로, 인프라 구성 시 XFS(reflink 활성화)나 Btrfs 같은 스토리지를 반드시 사전에 벤치마킹해야 한다.

[ 기존 PG17 복구 흐름 ] 

[ PG18 Clone 복구 흐름 ]

Clone 적용 조건

• 지원 파일시스템: XFS(reflink=1 활성화), Btrfs, ZFS
• XFS reflink 활성화 확인

• EXT4, NFS 등 CoW 미지원 환경에서는–clone 옵션 사용 불가 (오류 발생)

테스트

• 목적: pg_combinebackup 병합 시간에 대한 PG17 vs PG18 AIO 효과를 정량 검증한다.

테스트 환경

* PG17은 io_method 파라미터 없음

• 고정 조건: pgbench scale 5000(75GB) + change_target 테이블 / 전체 백업 + 증분 백업(zstd 압축) /
  3회 반복  중앙값 채택 / 매 실행 전 캐시 초기화

AIO + 증분 + 압축의 결합 효과

인사이트

PG18 worker는 왜 PG17보다 느린가.

워커 프로세스 생성과 컨텍스트 스위칭 오버헤드가 75GB 단일 병합에서 이점을 상쇄했다. worker는 대규모 동시 I/O 환경에서 유리하며, 단일 병합 작업에서는 sync 대비 이점이 크지 않다.

io_uring은 병합 시간을 29% 단축한다.

커널 레벨 비동기 I/O로 읽기·쓰기를 겹쳐 실행, 127초 → 90초. 데이터셋이 크거나 병합 체인이 길어질수록 차이는 더 벌어진다.

Clone이 게임 체인저다 — 시간 63배, 디스크 53배 절감.

–clone은 XFS reflink(CoW)로 전체 백업 블록 복사 없이 참조만 한다. 병합 시간 127초 → 2초, 실제 디스크 증가량 76.51GB → 1.45GB. XFS reflink 환경이라면 –clone 옵션은 선택이 아닌 필수다.

마치며

이 아티클에서 확인한 것은 단순한 설정값의 차이가 아니다. 같은 하드웨어, 같은 데이터베이스에서 무엇을 선택하느냐에 따라 백업 파이프라인의 성능과 복구 능력이 근본적으로 달라진다는 사실이다.

아래 표는 각 섹션의 핵심 결론과 실무 적용 지점을 요약한 것이다. “지금 당장 무엇을 바꿔야 하는가”에 대한 출발점으로 활용하기를 권한다.

백업 전략은 한 번 설정하고 잊는 것이 아니다. 데이터 규모, 네트워크 환경, 복구 목표가 달라질 때마다 설정을 다시 검토해야 한다. 이 아티클이 각자의 환경에 맞는 설정을 고르는 데 실질적인 기준이 되기를 바란다.