▲

pgbackrest는 더 이상 유지보수 되지 않음

 (github.com/pgbackrest)
3P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • PostgreSQL용 백업·복구 도구로서 대규모 환경까지 확장되도록 설계됐지만, 이제 유지보수를 종료 함
  • bug fix, PR review, 이슈 대응, 신규 기능 개발이 모두 중단됐고, 불규칙하게 끌고 가기보다 명확히 멈추는 쪽을 택함
  • 전체·differential·incremental 백업과 block-level backup, 중단된 작업 재개, delta restore를 지원해 변경된 부분만 저장·복구할 수 있음
  • 로컬·원격 환경을 아우르는 protocol layer와 multiple repositories를 갖추고, TLS·SSH 연결과 S3·Azure·GCS 호환 object store를 통해 운영 범위를 넓힘
  • checksum, WAL segment 대기, fsync, page checksum 검증 같은 무결성 보장 장치를 폭넓게 갖춘 도구였지만, 앞으로는 fork가 나오더라도 별도 신뢰를 새로 쌓아야 함

유지보수 종료와 프로젝트 상태

  • pgBackRest는 PostgreSQL용 백업·복구 도구이지만, 현재는 더 이상 유지보수되지 않음
  • 프로젝트 작업을 중단했고, 앞으로는 bug fix, PR review, 이슈 대응, 신규 기능 개발에 시간을 쓰지 않겠다고 밝힘
  • 기존 후원과 고용 형태가 끊긴 뒤에도 유지보수를 이어가려 했지만, 프로젝트를 계속 유지할 만큼의 직무 기회와 스폰서십을 확보하지 못함
  • 유지보수를 불규칙하거나 불완전하게 이어가기보다, 명확하게 종료하는 편이 더 낫다고 봄
  • 향후 누군가가 fork할 수는 있지만, 그 경우에는 새 프로젝트로 간주되며 새로운 유지보수자가 별도로 신뢰를 쌓아야 함

프로젝트의 핵심 기능

  • 대규모 PostgreSQL 환경까지 확장 가능한 백업·복구를 목표로 하며, 현재 안정 버전은 v2.58.0임
  • 병렬 처리와 lz4, zstd 같은 압축 방식을 활용해 백업 시 병목이 되기 쉬운 압축 비용을 줄이도록 설계됨
  • 전체, differential, incremental 백업을 지원하고, 파일 단위뿐 아니라 block-level backup으로 변경된 부분만 복사해 저장 공간을 절약함
  • 중단된 백업을 재개할 수 있고, manifest의 체크섬과 비교해 이미 복사한 파일의 무결성을 다시 확인함
  • delta restore에서는 백업에 없는 파일을 먼저 제거하고 남은 파일의 체크섬을 대조해, 일치하는 파일은 그대로 두고 필요한 파일만 복구함

원격 운용과 저장소 설계

  • 자체 protocol layer를 통해 로컬과 원격 환경 모두에서 백업, 복구, 아카이브 작업을 수행할 수 있으며, 원격 연결에는 TLS/SSH를 사용함
  • 같은 protocol layer로 PostgreSQL 질의 인터페이스도 제공해, PostgreSQL에 직접 원격 접속하지 않고도 작업할 수 있어 보안성을 높임
  • multiple repositories를 지원해, 빠른 복구용 로컬 저장소와 장기 보관·중복성 확보용 원격 저장소를 함께 둘 수 있음
  • 저장소는 S3, Azure, GCS 호환 object store에도 둘 수 있어 용량과 보존 기간을 크게 늘릴 수 있음
  • 저장소 자체를 암호화할 수 있어 백업 데이터가 어디에 저장되든 보호 가능함

무결성과 일관성 보장 방식

  • 백업의 모든 파일에 대해 checksum을 계산하고, restore나 verify 때 다시 검사함
  • 파일 복사가 끝난 뒤에는 백업을 일관된 상태로 만들기 위해 필요한 모든 WAL segment가 저장소에 도착할 때까지 대기함
  • 모든 작업에서 파일과 디렉터리 수준의 fsync를 사용해 내구성을 확보함
  • PostgreSQL에서 page checksum이 켜져 있으면, 전체 백업에서는 모든 파일의 페이지 체크섬을 검증하고 differential·incremental 백업에서는 변경된 파일만 검증함
  • 페이지 체크섬 검증에 실패해도 백업은 중단되지 않지만, 어떤 페이지가 실패했는지 경고를 남겨 유효한 백업이 만료되기 전에 page-level corruption을 조기에 찾을 수 있게 함

WAL 처리와 복구 성능 최적화

  • WAL push/get 전용 명령을 제공하며, 둘 다 병렬 처리와 비동기 실행을 지원해 PostgreSQL 응답 시간을 최대한 빠르게 맞추도록 설계됨
  • WAL push는 동일한 WAL segment가 여러 번 들어오면 자동으로 중복을 제거하고, 내용이 다르면 오류를 발생시킴
  • 비동기 WAL push는 다른 프로세스가 전송을 맡아 WAL segment를 병렬 압축하므로, 쓰기량이 매우 높은 데이터베이스에서 특히 중요함
  • 비동기 WAL get은 압축 해제된 WAL queue를 로컬에 유지해 replay 전에 바로 공급할 수 있게 하며, 지연 시간이 큰 연결이나 S3 같은 저장소에서 특히 이점이 커짐
  • WAL push와 get 모두 PostgreSQL 버전과 system identifier를 비교해 데이터베이스와 저장소가 맞는지 확인하므로, WAL archive 위치를 잘못 구성할 가능성을 크게 줄임

운영 유연성과 호환성

  • backup retention과 archive expiration 정책을 full, differential, WAL 단위로 나눠 설정할 수 있어 원하는 기간 범위를 커버할 수 있음
  • 백업을 PostgreSQL cluster 형식 그대로 저장할 수 있고, 압축을 끄고 hard link를 켜면 저장소 snapshot 위에서 PostgreSQL cluster를 직접 기동할 수도 있음
  • 이런 방식은 전통적인 restore에 시간이 오래 걸리는 terabyte-scale database에서 유리함
  • tablespace를 완전히 지원하며, restore 시 각 tablespace를 다른 위치로 옮기거나 한 위치로 일괄 remap할 수 있음
  • 파일과 디렉터리 링크도 지원해, restore 때 원래 위치 유지, 일부 또는 전체 remap, 일반 파일·디렉터리로 변환 복구까지 가능함
  • PostgreSQL 10개 버전을 지원하며, 현재 지원 중인 5개 버전과 EOL된 최근 5개 버전을 포함해 업그레이드 시간을 넉넉하게 확보하도록 구성됨

참고 리소스와 후원 상태

함께 보면 좋은 글 β

▲
GN⁺ 12시간전  [-]
Hacker News 의견들
  • 작성자가 LinkedIn에 올린 글을 보면, 13년간 pgBackRest에 쏟아온 시간과 애정이 정말 컸고 이제는 유지 중단을 결정했다고 함
    회사 후원도 있었지만 야간과 주말까지 갈아 넣어 왔고, Crunchy Data 매각 뒤에는 계속 유지하면서도 이 일을 이어갈 자리를 찾았지만 잘되지 않았다고 함
    생계를 위해 더 넓은 기회를 봐야 하고, 그러면 유지보수·버그 수정·PR 리뷰·이슈 대응에 필요한 시간을 더는 낼 수 없어 저장소를 아카이브하겠다는 입장임
  • 개인 프로젝트에서 pgBackRest를 써서 로컬 볼륨과 클라우드 저장소용 PostgreSQL 백업 가이드까지 만들 정도로 잘 써 왔는데, 이런 식으로 끝나게 되어 아쉽다고 느낌
    가이드는 https://github.com/freakynit/postgre-backup-and-restore-guide이고, 그동안 쏟아부은 시간과 노력에 정말 감사함
    • 요즘은 AI 기대치 때문에 개발자들이 더 빡빡한 마감에 시달리며 시간이 줄어든 면도 있다고 봄
      거기에 토큰에 돈을 태워 버린 사람들도 많아서, 여유 자금도 시간도 함께 줄어든 경우가 있음
    • 이런 프로젝트가 계속 자금 지원을 받지 못해 사라지는 일이 없었으면 좋겠고, OSS의 현실적인 어려움이 너무 크다고 느낌
  • 여기서는 오픈소스 모델 자체가 실패한 게 아니라, 작성자가 더는 재정 지원을 못 찾아서 방향을 바꾸는 것뿐이고 그건 충분히 타당하다고 봄
    이게 취미 프로젝트를 넘어 상업 환경에서 실제 가치를 주는 제품급 도구였다면, 그 틈새를 메울 영리 기업이 들어올 기회도 분명 있음
    다만 사용자가 고객이 되어 실제로 돈을 내야 하고, 무료 유지보수자에게 버그 리포트와 불만을 계속 보내는 식으로는 지속 가능하지 않음
    FOSS 재정 지속성에 대한 새 해법이 필요하고, 기부만으로는 부족해 보임
    • 어떤 생태계든 내가 원하면 직접 지원해서 살아남게 도와야 한다고 배움
      동네 가게든 오픈소스 프로젝트든 마찬가지임
    • 작성자가 이걸 유료 제품화하는 방안을 검토했는지도 궁금함
      다만 기여자마다 저작권이 걸려 있을 수 있어서 ACL 여부와 관할에 따라 권리 정리가 필요하고, 수익 배분 같은 합의도 필요할 수 있음
  • 사람들이 더 주목해야 할 건 Crunchy Data 인수 쪽이라고 봄
    기업 후원이 있을 때는 굴러갔는데 회사가 팔리고 새 주인이 우선순위를 바꾸자 3.8k-star 인프라 도구가 바로 불안정해졌고, 내 백업 도구의 자금줄이 남의 M&A 전략에 달려 있었다는 걸 사용자들은 모르고 있었던 셈임
    그래서 나도 조금씩 SQLite와 git으로 추적하는 파일 쪽으로 옮기고 있음
    관리형 Postgres 스택도 결국 자금 사정을 알 수 없는 사람들이 유지하는 여러 도구 위에 올라가 있기 때문임
    • 완전히 사라진 건 아니고, 적어도 지금 당장 백업이 멈추는 상황은 아니라고 봄
      다만 자금 구조가 취약하다는 큰 흐름 자체는 여전히 맞는 얘기임
    • 그런데 SQLite도 같은 위험에서 완전히 자유로운 건 아닌데, 왜 더 안전하다고 보는지 궁금함
  • 소스는 여전히 있으니, 안타깝다고만 하지 말고 직접 포크해서 유지하거나 누군가에게 비용을 내고 맡기는 선택지도 있음
    그러는 김에 잃기 싫은 의존 프로젝트들을 돌아보고 지금 바로 후원부터 설정하는 편이 맞다고 봄
    • 이 태도가 맞다고 생각함
      다들 슬프다고는 하는데, 정말 슬프다면 기부할 만큼 슬픈지부터 물어봐야 함
  • 내가 제대로 생태계를 봤을 때 pgBackRest는 PostgreSQL 백업 분야의 최고 솔루션이었음
    특히 단순히 백업만이 아니라 복구와 검증까지 진지하게 다뤘다는 점이 드물었고, 그걸 소홀히 했다가 직장에서 크게 데인 적도 있음
    자세한 얘기는 https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/에 있음
    그래서 이건 꽤 큰 손실로 느껴짐
  • 꽤 놀랍고, 나는 이게 사실상 대표적인 PG 백업/복구 도구라고 생각하고 있었음
    WAL-G나 Barman이랑 비교하면 어떤지 궁금함
    https://github.com/wal-g/wal-g
    https://github.com/EnterpriseDB/barman
    • 정확한 비교는 못 하겠지만, 우리는 Barman을 오래 써 왔고 매우 만족하고 있음
      매일 밤 Barman으로 복원한 nightly DB를 만들어 사용자 교육/테스트용으로도 돌려서 백업이 실제로 깨졌는지 계속 검증하는데, 수년째 문제 없었음
    • 나는 wal-g 유지관리자 중 한 명인데, 기능 면에서 충분히 비교 가능한 수준이라고 봄
      몇 년 비활성 상태였다가 다시 managed Postgres 쪽으로 돌아왔고, wal-g가 자체 블록 비교로 제공하는 delta backup에 더해 pg17 incremental backup도 지원되길 바라고 있음
      그리고 daemon mode는 꼭 쓰는 편이 좋음
      경쟁 도구가 사라지는 건 아쉽지만 이 영역은 아직 개선 여지가 많고, Postgres가 overcommit 없는 시스템에서 돌고 싶어 할 때는 C가 Golang보다 나은 점도 있음
    • 우리는 예전엔 WAL-E, 지금은 후속작인 WAL-G를 만족스럽게 써 왔음
      약 9년 전 검토할 때는 streaming PITR 특성 때문에 pgBackRest보다 이쪽이 더 끌렸음
    • 이게 대표 도구라고 여겼던 건 이해하지만, https://xkcd.com/2347/ 같은 상황도 떠오름
  • 나는 2TB 운영 DB에서 pgBackRest를 만족스럽게 써 왔고, 하필 이번 주에 8TB DB에도 붙일 생각이었음
    그럼 이제 가장 가까운 대안이 wal-g인지, barman인지, databasus인지 궁금함
    DBA 흉내만 내고 있다고 말하긴 했지만 실제론 선택이 꽤 중요함
    • 30TB+급 DB에서 Barman을 써 봤는데 별 불만 없었음
      참고로 나는 DBRE임
    • 멀티테라바이트 운영 Postgres를 백업하고 있다면 그건 DBA 흉내 수준이 아니라 이미 제대로 하고 있는 거라고 봄
    • 클라우드 저장소에 백업을 두는 구성이면 hook scripts를 붙인 Barman이 가장 가까운 대안일 듯함
      관련 문서는 https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman임
      https://github.com/aiven-open/pghoard도 괜찮아 보이지만 아직 직접 검증해 보진 않았음
    • 누가 standby를 ZFS나 다른 스냅샷 가능한 파일시스템 위에 두고 백업해 본 적 있는지도 궁금함
    • 나는 pgBackRest를 써 본 적도 없었는데, 딱 2시간 전에 한 프로젝트에 붙이기 시작했고 README를 다 읽고 나니 이미 업데이트돼 있었음
  • pgBackRest는 PostgreSQL 백업 기술 중에서도 가장 다재다능한 축에 들고, 내 경험상 다른 제품들이 여기까지 따라오진 못함
    그래서 이런 일이 더 아쉽고, 이 훌륭한 도구와 기능 동등성을 맞추는 건 쉽지 않을 듯함
    가능하다면 되돌릴 수 있는 결정이길 바라고, 아니면 PostgreSQL 프로젝트가 contrib로 흡수하는 방안도 있었으면 함
  • 아직은 계속 사용 가능하니 그냥 써도 됨
    작성자도 아마 사람들이 당장 버리기보다, 정말 더는 작동하지 않을 때까지는 계속 써 주길 바랄 것 같음
    • 그리고 그때쯤엔 누군가가 새 유지관리자로 나서 주면 좋겠음
      포크가 필요한지, 아니면 기존 저장소에 기여자로 들어가 이어받을 수 있는지는 잘 모르겠음
답변달기