pg_dump는 백업 도구인가?

최근에 PostgreSQL을 오랫동안 사용한 사람들이 "pg_dump는 백업 도구가 아니다"라는 말을 반복하는 것을 자주 듣습니다. 사실 문서도 최근에 수정되어 pg_dump를 백업 도구로 설명하지 않도록 변경되었고, 많은 사람들이 이에 안도하는 분위기입니다.

경험이 풍부한 PostgreSQL 사용자와 개발자가 pg_dump가 실제로 백업 도구라고 주장했다가 공개적으로 비난받는 사례도 있었습니다.

저는 이 이야기가 조금 아쉽게 느껴집니다.

이 주장이 사실이 아니기 때문입니다. 2024년 7월 31일 이전까지 문서에서는 오랫동안 pg_dump를 백업 도구로 설명해왔습니다. 이 문구는 2003년 4월 17일에 추가되었습니다.

물론, 문서가 20년 넘게 특정 내용을 담고 있었다고 해서 그것이 자동으로 사실이 되는 것은 아닙니다. 그러나 pg_dump와 pg_dumpall을 적절히 사용하면 데이터베이스의 모든 데이터를 저장하고 나중에 새로운 데이터베이스로 로드할 수 있습니다.

저는 몇 번의 프로젝트 동안 그렇게 해왔고, 그 방식이 저에게 잘 맞았습니다. 만약 데이터베이스가 다운되고 데이터 디렉토리의 내용을 잃어버린다면, 저장한 덤프에서 복구해 시스템을 다시 가동할 수 있었습니다.

재해가 발생했을 때 데이터를 복구하고 시스템을 다시 가동할 수 있게 해주는 도구를 뭐라고 부를까요? 저는 그것을 백업 도구라고 부릅니다.

물론, 저는 이 방법을 일반 사용자에게 권장하지는 않습니다. 당시 제가 작업하던 PostgreSQL 데이터베이스는 오늘날의 기준으로도 매우 작은 데이터베이스였고, 사용자도 적었습니다.

pg_dump를 사용해 큰 데이터베이스를 백업하면 시간이 매우 오래 걸릴 수 있으며, 복원하는 데도 시간이 오래 걸릴 수 있습니다.

pg_dump는 실행 중에 MVCC 스냅샷을 유지하기 때문에 백업 시간이 길어지면 리소스 사용 문제가 발생할 수 있으며, 이로 인해 데이터베이스가 팽창하여 이후 VACUUM 또는 심지어 VACUUM FULL을 수행해야 하는 상황이 발생할 수 있습니다.(상상하고 싶지 않은 일이죠.)

PostgreSQL을 경험한 사용자라면 문제를 수작업으로 해결하면 되고, 그런 문제를 직접 해결한 경우도 있습니다.

예를 들어, pg_dump를 사용해 덤프한 후 최신 버전의 데이터베이스로 복원하려고 하면 오류가 발생할 수 있습니다. pg_dump 버전이 서버 버전과 일치할 경우 이러한 문제가 발생하지 않아야 하지만, 구버전의 덤프를 최신 버전으로 복원하려다 보면 문제가 발생할 수 있고, 종종 덤프를 수동으로 수정해야 했습니다.

또한 pg_dump를 사용할 때는 각 데이터베이스마다 개별적으로 pg_dump를 실행하고, 전역 객체를 저장하기 위해 pg_dumpall -g도 실행해야 하며, pg_hba.conf나 postgresql.conf 같은 구성 파일도 백업해야 한다는 점을 잊지 말아야 합니다. (놓치기 쉬운 부분입니다.)

이 문제는 pg_dump의 또 다른 약점으로 이어집니다. pg_dump는 백업을 자동으로 관리해주지 않습니다. 예를 들어, 최근 N개의 백업을 유지하고 싶다면 pg_dump는 아무런 도움을 주지 않습니다.

전역 객체(pg_dumpall -g에서)와 각 데이터베이스 객체(pg_dump에서)를 적절한 순서로, 적절한 병렬성으로 복원하는 데도 아무런 도움을 주지 않습니다. 덤프를 tar 형식으로 할지, 커스텀 형식으로 할지도 전적으로 사용자가 알아서 결정해야 합니다.

이러한 이유와 다른 이유들로 인해 대부분의 경우 pg_dump보다는 barman이나 backrest 같은 전문적으로 작성된 백업 도구를 사용하는 것이 더 나을 것입니다.

이러한 도구들은 데이터베이스 파일의 물리적 복사본과 데이터베이스를 일관되게 만드는 데 필요한 WAL 파일을 함께 백업해줍니다. 이러한 방식으로 point-in-time 복구를 할 수 있으며, pg_dump를 사용해 하루에 한 번 백업하는 경우 재해가 발생하면 마지막 백업 시점으로 돌아가야 하고 그 이후의 모든 변경사항은 손실됩니다.

반면, 제대로 구성된 백업 도구를 사용하면 마지막 백업 이후 생성된 모든 WAL을 재생할 수 있어 몇 초 내지 거의 데이터 손실이 없을 수 있습니다.

하지만 이러한 점들이 pg_dump가 백업 도구가 아니라는 것을 의미하지는 않습니다. 그것은 단지 대부분의 사람들에게는 pg_dump가 적합한 백업 도구가 아니라는 것을 의미할 뿐입니다.

사용 사례에 따라 pg_dump가 더 적합하다면 주저하지 말고 사용하십시오.

PostgreSQL을 처음 사용하던 시절, 모든 데이터를 텍스트 형식으로 백업하는 방식이 마음에 들었습니다. 텍스트 파일을 읽고 이해할 수 있었기 때문에 어떤 일이 발생해도 데이터를 복구할 수 있다는 자신감이 있었습니다.

오늘날에도 여전히 데이터베이스의 논리적 복사본을 갖고 싶을 때가 있을 수 있으며, 데이터 크기가 크다면 논리적 복제를 사용하는 방법도 고려할 것입니다.

물리적 백업에만 의존하면 데이터 손상 시 그 손상이 모두 복제될 가능성이 있습니다. 논리적 복사본을 사용하면 손상된 데이터가 복제되지 않고 문제가 발생하면 이를 빠르게 감지하고 대응할 수 있습니다.

제 의견:

pg_dump는 작은 규모의 데이터베이스나 간단한 데이터 구조를 다룰 때 충분히 유용한 백업 도구가 될 수 있습니다. 하지만 대규모 데이터베이스나 복잡한 환경에서는 더 완전한 백업 및 복구 도구를 사용하는 것이 더 적합할 수 있습니다. 결국 중요한 것은 사용자의 요구 사항과 환경에 맞는 백업 전략을 선택하는 것이며, 그 과정에서 pg_dump가 좋은 선택이 될 수 있습니다.

나의 말: