파일 시스템 수준 백업

파일 시스템 수준 백업 (File System Level Backup)

pg_dump가 SQL 문장을 뽑아내는 백업이라면, 파일 시스템 백업은 PostgreSQL이 데이터를 저장할 때 실제로 쓰는 파일들을 통째로 복사하는 방식이에요. 누가 봐도 단순해 보이는데요, 이 방법에는 만만치 않은 제약이 둘이 있어서 실무에서는 조건부로만 쓸 수 있어요. 어떤 제약인지, 그리고 스냅샷을 활용하는 더 나은 변형은 어떤 건지 함께 살펴볼게요.

출처: 공식문서

데이터 파일을 통째로 복사하는 방법

데이터 파일의 위치는 공식문서 Section 18.2에서 확인할 수 있어요. 어떤 도구로 복사하든 상관없는데, 예를 들면 이렇게 tar로 압축할 수 있어요.

tar -cf backup.tar /usr/local/pgsql/data

그런데 이 방법은 아래 두 가지 제약 때문에 실용적이지 않거나, 최소한 pg_dump 방식보다 못해요.

  1. 서버를 꺼야만 쓸 만한 백업이 나와요. 연결을 막는 식의 중간 정도 조치는 소용없어요. 그 이유는 tar 같은 도구가 파일 시스템 상태를 원자적으로(atomic) 스냅샷하지도 않을뿐더러, 서버 내부 버퍼링 때문이기도 해요. 데이터를 복원할 때도 마찬가지로 서버를 먼저 꺼야 해요.
  2. 개별 테이블이나 개별 DB만 골라 백업·복원할 수 없어요. 파일만 복사한 정보는 커밋 로그 파일인 pg_xact/*(모든 트랜잭션의 커밋 상태를 담고 있어요) 없이는 쓸 수 없어요. 테이블 파일은 그 정보가 있어야만 사용 가능하거든요. 테이블 하나와 그 pg_xact 데이터만 복원하는 것도 불가능한데, 그렇게 하면 클러스터의 다른 모든 테이블이 망가지기 때문이에요. 그래서 파일 시스템 백업은 데이터베이스 클러스터 전체를 통째로 백업하고 복원할 때만 동작해요.

스냅샷을 쓰면 서버를 끄지 않아도 돼요

파일 시스템이 지원한다면(그리고 그 기능이 제대로 구현됐다고 신뢰한다면) 데이터 디렉터리의 '일관된 스냅샷(consistent snapshot)'을 만드는 방식이 또 있어요. 전형적인 절차는 이렇습니다.

  1. 데이터베이스가 담긴 볼륨의 '얼린 스냅샷(frozen snapshot)'을 만든다.
  2. 스냅샷에서 데이터 디렉터리 전체(일부가 아니라, 위에서 말한 것처럼 전부)를 백업 장치로 복사한다.
  3. 얼린 스냅샷을 해제한다.

이 방식은 데이터베이스 서버가 실행 중이어도 동작해요. 다만 이렇게 만든 백업은 마치 서버가 제대로 종료되지 않았던 상태의 파일들로 저장돼요. 그래서 백업된 데이터로 서버를 시작하면, 서버는 이전 인스턴스가 크래시했다고 생각하고 WAL 로그를 재생(replay)하게 돼요. 문제가 되는 건 아니니 참고만 하면 되고, 백업에 WAL 파일을 반드시 포함시키는 것만 잊지 말아요. 스냅샷을 찍기 전에 CHECKPOINT를 실행하면 복구 시간을 줄일 수 있어요.

여러 파일 시스템에 걸쳐 있다면?

데이터베이스가 여러 파일 시스템에 흩어져 있으면 모든 볼륨의 얼린 스냅샷을 정확히 동시에 얻지 못할 수도 있어요. 예를 들어 데이터 파일과 WAL 로그가 다른 디스크에 있거나, 테이블스페이스가 서로 다른 파일 시스템에 있다면 스냅샷 방식이 불가능할 수 있어요 — 스냅샷이 동시에 찍혀야 하기 때문이에요. 그런 상황에서 스냅샷 기법을 믿기 전에 파일 시스템 문서를 아주 신중히 읽어야 해요.

동시 스냅샷이 불가능할 때 선택지가 두 가지 있어요.

  • 모든 얼린 스냅샷을 만들 수 있을 만큼만 데이터베이스 서버를 끄는 방법.
  • 연속 아카이빙 베이스 백업(continuous archiving base backup) 을 쓰는 방법. 이 백업은 백업 도중 파일 시스템 변화에 영향받지 않아서 좋아요. 백업 과정 동안만 연속 아카이빙을 켜고, 복원은 연속 아카이브 복구로 진행하면 돼요.

또 다른 대안은 rsync로 파일 시스템 백업을 하는 거예요. 먼저 서버가 실행 중일 때 rsync로 한 차례 돌린 뒤, 서버를 잠깐 꺼서 rsync --checksum을 실행하는 방식이에요. (--checksum이 필요한 이유는 rsync가 파일 수정 시각을 1초 단위까지만 보기 때문이에요.) 두 번째 rsync는 전송할 데이터가 적어서 첫 번째보다 빠르고, 서버가 꺼진 상태에서 실행됐으므로 결과도 일관돼요. 이 방법은 가동 중단 시간을 최소화하면서 파일 시스템 백업을 가능하게 해줘요.

한 가지 알아둘 점은, 파일 시스템 백업은 보통 SQL 덤프보다 크다는 거예요. (pg_dump는 예를 들어 인덱스 내용을 덤프하지 않고 재생성 명령만 뽑아내거든요.) 하지만 파일 시스템 백업을 만드는 속도는 더 빠를 수 있어요.

더 알아보기 (Learn more)