# pgbackrest는 더 이상 유지보수 되지 않음 > Clean Markdown view of GeekNews topic #28965. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28965](https://news.hada.io/topic?id=28965) - GeekNews Markdown: [https://news.hada.io/topic/28965.md](https://news.hada.io/topic/28965.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-28T09:56:12+09:00 - Updated: 2026-04-28T09:56:12+09:00 - Original source: [github.com/pgbackrest](https://github.com/pgbackrest/pgbackrest) - Points: 3 - Comments: 1 ## Topic Body - 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](https://github.com/pgbackrest/pgbackrest/releases/tag/release/2.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](https://github.com/pgbackrest/pgbackrest)에도 둘 수 있어 용량과 보존 기간을 크게 늘릴 수 있음 - 저장소 자체를 **암호화**할 수 있어 백업 데이터가 어디에 저장되든 보호 가능함 ### 무결성과 일관성 보장 방식 - 백업의 모든 파일에 대해 **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개 버전을 포함해 업그레이드 시간을 넉넉하게 확보하도록 구성됨 ### 참고 리소스와 후원 상태 - [User guides](http://www.pgbackrest.org/user-guide-index.html) - [Command reference](http://www.pgbackrest.org/command.html) - [Configuration reference](http://www.pgbackrest.org/configuration.html) - 현재 스폰서는 [Supabase](https://supabase.com)임 - 과거 스폰서로는 [Crunchy Data](https://crunchydata.com), [Resonate](https://resonate.com)가 있었음 ## Comments ### Comment 56443 - Author: neo - Created: 2026-04-28T09:56:13+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47919997) - 작성자가 LinkedIn에 올린 글을 보면, **13년간 pgBackRest**에 쏟아온 시간과 애정이 정말 컸고 이제는 **유지 중단**을 결정했다고 함 회사 후원도 있었지만 야간과 주말까지 갈아 넣어 왔고, Crunchy Data 매각 뒤에는 계속 유지하면서도 이 일을 이어갈 자리를 찾았지만 잘되지 않았다고 함 생계를 위해 더 넓은 기회를 봐야 하고, 그러면 유지보수·버그 수정·PR 리뷰·이슈 대응에 필요한 시간을 더는 낼 수 없어 저장소를 아카이브하겠다는 입장임 - 개인 프로젝트에서 **pgBackRest**를 써서 로컬 볼륨과 클라우드 저장소용 PostgreSQL 백업 가이드까지 만들 정도로 잘 써 왔는데, 이런 식으로 끝나게 되어 아쉽다고 느낌 가이드는 [https://github.com/freakynit/postgre-backup-and-restore-guide](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/](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/wal-g/wal-g) [https://github.com/EnterpriseDB/barman](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/](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://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](https://github.com/aiven-open/pghoard)도 괜찮아 보이지만 아직 직접 검증해 보진 않았음 - 누가 **standby를 ZFS**나 다른 스냅샷 가능한 파일시스템 위에 두고 백업해 본 적 있는지도 궁금함 - 나는 pgBackRest를 써 본 적도 없었는데, 딱 **2시간 전**에 한 프로젝트에 붙이기 시작했고 README를 다 읽고 나니 이미 업데이트돼 있었음 - **pgBackRest**는 PostgreSQL 백업 기술 중에서도 가장 다재다능한 축에 들고, 내 경험상 다른 제품들이 여기까지 따라오진 못함 그래서 이런 일이 더 아쉽고, 이 훌륭한 도구와 **기능 동등성**을 맞추는 건 쉽지 않을 듯함 가능하다면 되돌릴 수 있는 결정이길 바라고, 아니면 PostgreSQL 프로젝트가 contrib로 흡수하는 방안도 있었으면 함 - 아직은 **계속 사용 가능**하니 그냥 써도 됨 작성자도 아마 사람들이 당장 버리기보다, 정말 더는 작동하지 않을 때까지는 계속 써 주길 바랄 것 같음 - 그리고 그때쯤엔 누군가가 **새 유지관리자**로 나서 주면 좋겠음 포크가 필요한지, 아니면 기존 저장소에 기여자로 들어가 이어받을 수 있는지는 잘 모르겠음