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-GBarman이랑 비교하면 어떤지 궁금함
    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로 흡수하는 방안도 있었으면 함
  • 아직은 계속 사용 가능하니 그냥 써도 됨
    작성자도 아마 사람들이 당장 버리기보다, 정말 더는 작동하지 않을 때까지는 계속 써 주길 바랄 것 같음
    • 그리고 그때쯤엔 누군가가 새 유지관리자로 나서 주면 좋겠음
      포크가 필요한지, 아니면 기존 저장소에 기여자로 들어가 이어받을 수 있는지는 잘 모르겠음