pgBackRest artık bakım almıyor

 (github.com/pgbackrest)
3 puan yazan GN⁺ 2026-04-28 | 2 yorum | WhatsApp'ta paylaş
  • PostgreSQL için yedekleme·geri yükleme aracı olarak büyük ölçekli ortamlara kadar genişleyebilecek şekilde tasarlanmıştı, ancak artık bakımı sona erdi
  • bug fix, PR review, issue yanıtları ve yeni özellik geliştirme tamamen durduruldu; düzensiz biçimde sürdürmek yerine net şekilde durdurma tercih edildi
  • full·differential·incremental yedekleme ile block-level backup, kesintiye uğrayan işleri sürdürme ve delta restore destekleniyor; böylece yalnızca değişen kısımlar kaydedilip geri yüklenebiliyor
  • Yerel·uzak ortamları kapsayan bir protocol layer ve multiple repositories sunuyor; TLS·SSH bağlantıları ile S3·Azure·GCS uyumlu object store desteği sayesinde operasyon kapsamını genişletiyor
  • checksum, WAL segment bekleme, fsync, page checksum doğrulaması gibi bütünlük güvence mekanizmaları açısından oldukça kapsamlı bir araçtı; ancak bundan sonra bir fork çıksa bile ayrı olarak yeniden güven kazanması gerekecek

Bakımın sona ermesi ve projenin durumu

  • pgBackRest, PostgreSQL için bir yedekleme·geri yükleme aracı, ancak artık bakım almıyor
  • Proje çalışmaları durduruldu ve bundan sonra bug fix, PR review, issue yanıtları ve yeni özellik geliştirmeye zaman ayrılmayacağı açıklandı
  • Mevcut sponsorluk ve istihdam biçimleri sona erdikten sonra da bakım sürdürülmek istendi, ancak projeyi devam ettirecek düzeyde iş fırsatı ve sponsorluk sağlanamadı
  • Bakımı düzensiz ya da eksik biçimde sürdürmektense, net bir şekilde sonlandırmanın daha iyi olacağı değerlendirildi
  • İleride biri bir fork çıkarabilir, ancak bu durumda bu bir yeni proje sayılacak ve yeni bakımcının ayrıca güven oluşturması gerekecek

Projenin temel özellikleri

  • Büyük ölçekli PostgreSQL ortamlarına kadar genişleyebilen yedekleme·geri yükleme hedefleniyor ve mevcut kararlı sürüm v2.58.0
  • Paralel işleme ile lz4 ve zstd gibi sıkıştırma yöntemleri kullanılarak, yedekleme sırasında darboğaz olmaya yatkın sıkıştırma maliyetini azaltacak şekilde tasarlandı
  • full, differential, incremental yedeklemeyi destekliyor; dosya düzeyinin yanı sıra block-level backup ile yalnızca değişen bölümler kopyalanarak depolama alanı tasarrufu sağlanıyor
  • Kesintiye uğrayan yedeklemeler sürdürülebiliyor ve manifest içindeki checksum ile karşılaştırılarak daha önce kopyalanmış dosyaların bütünlüğü yeniden doğrulanıyor
  • delta restore aşamasında yedekte bulunmayan dosyalar önce kaldırılıyor, ardından kalan dosyaların checksum değerleri karşılaştırılıyor; eşleşen dosyalar olduğu gibi bırakılırken yalnızca gerekli dosyalar geri yükleniyor

Uzak operasyon ve depo tasarımı

  • Kendi protocol layer yapısı üzerinden hem yerel hem uzak ortamlarda yedekleme, geri yükleme ve arşiv işlemleri yapılabiliyor; uzak bağlantılarda TLS/SSH kullanılıyor
  • Aynı protocol layer ile PostgreSQL sorgu arayüzü de sunuluyor; böylece PostgreSQL'e doğrudan uzak bağlantı açmadan işlem yapılabildiği için güvenlik artırılıyor
  • multiple repositories desteği sayesinde, hızlı geri yükleme için yerel depo ile uzun süreli saklama ve yedeklilik için uzak depo birlikte kullanılabiliyor
  • Depolar S3, Azure, GCS uyumlu object store üzerinde de tutulabildiğinden kapasite ve saklama süresi önemli ölçüde artırılabiliyor
  • Deponun kendisi şifrelenebildiği için yedek verisi nerede tutulursa tutulsun korunabiliyor

Bütünlük ve tutarlılık sağlama yöntemleri

  • Yedekteki tüm dosyalar için checksum hesaplanıyor ve restore ya da verify sırasında yeniden kontrol ediliyor
  • Dosya kopyalama tamamlandıktan sonra, yedeği tutarlı bir duruma getirmek için gerekli tüm WAL segment dosyaları depoya ulaşana kadar bekleniyor
  • Tüm işlemlerde dosya ve dizin düzeyinde fsync kullanılarak dayanıklılık sağlanıyor
  • PostgreSQL'de page checksum açıksa, full yedeklemede tüm dosyaların page checksum değerleri doğrulanıyor; differential·incremental yedeklemede ise yalnızca değişen dosyalar doğrulanıyor
  • Page checksum doğrulaması başarısız olsa bile yedekleme durdurulmuyor; ancak hangi sayfanın başarısız olduğuna dair uyarı bırakılarak geçerli bir yedek süresi dolmadan önce page-level corruption erken tespit edilebiliyor

WAL işleme ve geri yükleme performansı optimizasyonu

  • WAL push/get için özel komutlar sunuluyor; her ikisi de paralel işleme ve asenkron çalışmayı destekleyerek PostgreSQL yanıt süresini mümkün olduğunca hızlı tutacak şekilde tasarlandı
  • WAL push, aynı WAL segment birden fazla kez gelirse bunu otomatik olarak tekilleştiriyor; içerik farklıysa hata oluşturuyor
  • Asenkron WAL push'ta aktarımı başka süreçler üstlenip WAL segmentlerini paralel olarak sıkıştırıyor; bu da özellikle yazma hacmi çok yüksek veritabanlarında önemli hale geliyor
  • Asenkron WAL get, sıkıştırması açılmış WAL queue yapısını yerelde tutarak replay öncesinde hemen besleme yapılmasını sağlıyor; gecikmesi yüksek bağlantılarda veya S3 gibi depolarda bunun avantajı özellikle büyük
  • Hem WAL push hem de get, PostgreSQL sürümü ile system identifier değerini karşılaştırarak veritabanı ile deponun eşleştiğini doğruluyor; böylece WAL archive konumunun yanlış yapılandırılması olasılığı büyük ölçüde azalıyor

Operasyonel esneklik ve uyumluluk

  • backup retention ve archive expiration politikaları full, differential ve WAL düzeyinde ayrı ayrı ayarlanabildiğinden istenen zaman aralığı kapsanabiliyor
  • Yedekler PostgreSQL cluster biçiminde olduğu gibi saklanabiliyor; sıkıştırma kapatılıp hard link etkinleştirilirse depo snapshot'ı üzerinde PostgreSQL cluster doğrudan da başlatılabiliyor
  • Bu yaklaşım, geleneksel restore işleminin uzun sürdüğü terabyte-scale database ortamlarında avantaj sağlıyor
  • tablespace tam olarak destekleniyor; restore sırasında her tablespace farklı bir konuma taşınabiliyor veya tek bir konuma toplu olarak remap edilebiliyor
  • Dosya ve dizin linkleri de destekleniyor; böylece restore sırasında özgün konumu koruma, bir kısmını veya tamamını remap etme ya da normal dosya·dizin olarak dönüştürerek geri yükleme mümkün oluyor
  • PostgreSQL'in 10 sürümü destekleniyor; buna şu anda desteklenen 5 sürüm ile EOL olmuş en son 5 sürüm dahil ve böylece yükseltme için geniş zaman bırakılıyor

Referans kaynakları ve sponsorluk durumu

İlgili okumalar

2 yorum

 
xguru 2026-05-05

Bununla ilgili bir güncelleme yapıldı.

  • pgBackRest bakımının durdurulacağını duyurduktan sonra posta kutusu mesaj yağmuruna tutuldu
  • Çok sayıda destek mesajı geldi
  • Birden fazla sponsorun ortak desteğiyle pgBackRest finansman buldu ve proje devam edebilecek hale geldi
  • Ayrıca iş yükünü dağıtmak ve projenin sürekliliğini korumak için bir bakım sorumlusu daha eklenmesinin beklendiği belirtildi
  • Mevcut pgBackRest sürümü düzgün çalışıyor ve ciddi bir hata ya da güvenlik sorunu bulunmadığı için projeyi hemen fork etmeye gerek yok
  • pgBackRest'ı yeniden canlandırmak için aktif olarak çalışılıyor
 
GN⁺ 2026-04-28
Hacker News yorumları
  • Yazarın LinkedIn’de paylaştığı yazıya bakılırsa, 13 yıldır pgBackRest için harcadığı zaman ve emek gerçekten çok büyüktü ve artık bakımı durdurma kararı almış
    Şirket desteği de vardı ama gecelerini ve hafta sonlarını da buna vermiş; Crunchy Data satıldıktan sonra da bakımı sürdürürken bu işi devam ettirebileceği bir pozisyon aramış ama işler istediği gibi gitmemiş
    Geçimini sağlayabilmek için daha geniş fırsatlara bakması gerekiyor ve bu durumda bakım, hata düzeltme, PR inceleme ve issue takibi için gereken zamanı artık ayıramayacağı için depoyu arşivleyeceğini söylüyor
  • Kişisel projelerde pgBackRest kullanmış, hatta yerel volume’ler ve bulut depolama için PostgreSQL yedekleme rehberi bile hazırlamış biri olarak bunu çok faydalı buluyordu; işlerin böyle bitmesine üzüldüğünü söylüyor
    Rehber şu adreste: https://github.com/freakynit/postgre-backup-and-restore-guide ve bugüne kadar verdiği tüm zaman ve emek için gerçekten teşekkür ediyor
    • Bugünlerde yapay zeka beklentileri yüzünden geliştiricilerin daha sıkışık teslim tarihleri altında çalıştığını ve zamanlarının daha da azaldığını düşünüyor
      Üstelik token’lara para gömen çok kişi olduğu için hem boşta para hem de zaman azalmış durumda olabiliyor
    • Bu tür projelerin yeterli finansman bulamadığı için yok olup gitmemesini dilediğini, açık kaynağın pratikte yaşadığı zorlukların çok büyük olduğunu söylüyor
  • Burada başarısız olan şeyin açık kaynak modelinin kendisi değil, yazarın artık finansal destek bulamayıp yön değiştirmesi olduğunu ve bunun da gayet makul olduğunu düşünüyor
    Eğer bu, hobi projesini aşarak ticari ortamda gerçek değer üreten ürün düzeyinde bir araçsa, bu boşluğu doldurmak için kâr amaçlı bir şirketin devreye girmesi için kesinlikle bir fırsat vardır
    Ama bunun için kullanıcıların müşteriye dönüşüp gerçekten para ödemesi gerekir; ücretsiz bakım yapan kişilere sürekli hata raporu ve şikayet göndermekle bu iş sürdürülebilir olmaz
    FOSS’un finansal sürdürülebilirliği için yeni çözümler gerektiğini, bağışların tek başına yeterli görünmediğini düşünüyor
    • Hangi ekosistem olursa olsun, gerçekten yaşamasını istiyorsam bizzat destek olmam gerektiğini öğrendiğini söylüyor
      Mahalledeki dükkân da olsa açık kaynak proje de olsa durum aynı
    • Yazarın bunu ücretli bir ürüne dönüştürme ihtimalini değerlendirip değerlendirmediğini merak ediyor
      Ancak katkı yapan herkesin telif hakkı devreye girebileceği için, ACL olup olmadığına ve yargı alanına bağlı olarak hakların düzenlenmesi gerekebilir; gelir paylaşımı gibi konularda da uzlaşı lazım olabilir
  • İnsanların daha çok dikkat etmesi gereken tarafın Crunchy Data satın alımı olduğunu düşünüyor
    Kurumsal destek varken her şey yürüyordu ama şirket satılıp yeni sahip öncelikleri değiştirince 3.8k yıldızlı bir altyapı aracı bir anda kırılgan hale geldi; yani kullanıcılar, kendi yedekleme araçlarının finansmanının başkalarının M&A stratejisine bağlı olduğunun farkında değildi
    Bu yüzden kendisi de yavaş yavaş SQLite ve git ile izlenen dosya tarafına kayıyor
    Çünkü yönetilen Postgres yığınları da sonuçta finansal durumunu bilmediğimiz kişilerin bakımını yaptığı birçok aracın üstüne kurulu
    • Tamamen ortadan kalkmış değil; en azından şu an için yedeklerin durduğu bir durum yok diye düşünüyor
      Yine de finansman yapısının kırılgan olduğu yönündeki büyük resim hâlâ geçerli
    • Ama SQLite da aynı risklerden tamamen muaf değil; neden daha güvenli görüldüğünü merak ediyor
  • Kaynak kod hâlâ duruyor; bu yüzden sadece üzülmek yerine doğrudan fork’layıp sürdürmek ya da birine ücret ödeyip bakımını üstlendirmek de bir seçenek
    Hazır bunu düşünüyorken, kaybetmek istemediğimiz bağımlı projeleri gözden geçirip daha şimdi destek vermeye başlamanın doğru olacağını söylüyor
    • Bunun doğru yaklaşım olduğunu düşünüyor
      Herkes üzgün olduğunu söylüyor ama gerçekten üzgünse önce bağış yapacak kadar üzgün mü diye sormak gerekir
  • Ekosistemi doğru gördüyse pgBackRest, PostgreSQL yedekleme alanındaki en iyi çözümdü
    Özellikle yalnızca yedekleme değil, geri yükleme ve doğrulama konularını da ciddiyetle ele alması çok nadirdi; bunları hafife almanın iş yerinde kendisine ağır patladığı da olmuş
    Ayrıntılar burada: https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
    Bu yüzden bunu oldukça büyük bir kayıp olarak görüyor
  • Bu epey şaşırtıcı; kendisi bunun fiilen önde gelen PG yedekleme/geri yükleme aracı olduğunu düşünüyormuş
    WAL-G ya da Barman ile karşılaştırınca durumun nasıl olduğunu merak ediyor
    https://github.com/wal-g/wal-g
    https://github.com/EnterpriseDB/barman
    • Tam bir karşılaştırma yapamayacağını söylüyor ama Barman’ı uzun süredir kullanıyorlar ve çok memnunlar
      Her gece Barman ile geri yüklenmiş bir nightly DB oluşturup bunu kullanıcı eğitimi ve test için de çalıştırıyorlar; böylece yedeklerin gerçekten bozuk olup olmadığını sürekli doğrulamış oluyorlar ve yıllardır sorun yaşamamışlar
    • Kendisi wal-g bakımcılarından biri ve özellik açısından rahatlıkla karşılaştırılabilir bir seviyede olduğunu düşünüyor
      Birkaç yıllık durgunluğun ardından tekrar managed Postgres tarafına döndüklerini ve wal-g’nin kendi blok karşılaştırmasıyla sunduğu delta backup’ın yanı sıra pg17 incremental backup desteğini de görmek istediğini söylüyor
      Ayrıca daemon mode’u kesinlikle kullanmak gerektiğini ekliyor
      Rakip bir aracın kaybolması üzücü ama bu alanda hâlâ geliştirilecek çok şey var; Postgres overcommit olmayan sistemlerde çalışmak istediğinde de C’nin Golang’a göre avantajları olabiliyor
    • Eskiden WAL-E, şimdi de onun halefi WAL-G’yi memnuniyetle kullanmışlar
      Yaklaşık 9 yıl önce değerlendirme yaparken streaming PITR özellikleri nedeniyle pgBackRest’ten daha cazip gelmiş
    • Bunun önde gelen araç sayılmasını anlıyor ama https://xkcd.com/2347/ gibi bir durumu da hatırlatıyor
  • Kendisi 2TB’lık üretim veritabanında pgBackRest’i memnuniyetle kullanıyormuş ve tam da bu hafta 8TB’lık veritabanına da eklemeyi planlıyormuş
    Şimdi en yakın alternatifin wal-g mi, barman mı, yoksa databasus mu olduğunu merak ediyor
    Kendisiyle ilgili “DBA taklidi yapıyorum” demiş ama aslında bu seçim oldukça önemli
    • 30TB+ ölçekli veritabanlarında Barman kullanmış biri olarak ciddi bir şikâyeti olmadığını söylüyor
      Not olarak da kendisinin DBRE olduğunu ekliyor
    • Çok terabaytlı üretim Postgres yedekliyorsan bunun DBA taklidi değil, işi gerçekten yapıyor olmak anlamına geldiğini söylüyor
    • Yedekleri bulut depolamada tutan bir kurulumsa, hook script’leri eklenmiş Barman en yakın alternatif gibi görünüyor
      İlgili doküman: 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 da iyi görünüyor ama henüz bizzat doğrulamamış
    • Kimsenin standby’ı ZFS ya da başka snapshot alabilen bir dosya sistemi üstünde tutup oradan yedek almayı deneyip denemediğini merak ediyor
    • Kendisi pgBackRest’i daha önce hiç kullanmamış ama tam 2 saat önce bir projeye eklemeye başlamış; README’yi bitirdiğinde çoktan güncellenmişti
  • pgBackRest, PostgreSQL yedekleme teknolojileri arasında en çok yönlü olanlardan biri ve kendi deneyimine göre diğer ürünler bu seviyeye tam ulaşamıyor
    Bu yüzden olanlar daha da üzücü ve bu harika araçla özellik eşdeğerliği yakalamak kolay olmayacak gibi görünüyor
    Mümkünse geri alınabilir bir karar olmasını umuyor; olmazsa PostgreSQL projesinin bunu contrib olarak bünyesine katmasının da iyi olacağını düşünüyor
  • Şimdilik kullanmaya devam edilebilir, yani olduğu gibi kullanılabilir
    Yazara göre de insanlar muhtemelen bunu hemen terk etmek yerine, gerçekten artık çalışmaz hale gelene kadar kullanmaya devam etse daha iyi olur
    • Ve o zamana kadar birilerinin yeni bakımcı olarak ortaya çıkmasını umuyor
      Bunun için fork gerekip gerekmediğini ya da mevcut depoya katkıcı olarak eklenip oradan devralmanın mümkün olup olmadığını bilmediğini söylüyor