pgBackRest tidak lagi dipelihara

 (github.com/pgbackrest)
3 poin oleh GN⁺ 20 hari lalu | 2 komentar | Bagikan ke WhatsApp
  • Sebagai alat backup dan pemulihan untuk PostgreSQL yang dirancang agar dapat diskalakan hingga lingkungan besar, kini proyek ini menghentikan pemeliharaan
  • bug fix, review PR, penanganan isu, dan pengembangan fitur baru semuanya telah dihentikan, dan dipilih untuk berhenti secara jelas daripada meneruskannya secara tidak teratur
  • Mendukung backup full, differential, incremental, serta block-level backup, melanjutkan pekerjaan yang terputus, dan delta restore sehingga hanya bagian yang berubah yang disimpan dan dipulihkan
  • Memiliki protocol layer yang mencakup lingkungan lokal maupun jarak jauh serta multiple repositories, dan memperluas cakupan operasional melalui koneksi TLS·SSH dan object store kompatibel S3·Azure·GCS
  • Ini adalah alat yang memiliki beragam mekanisme jaminan integritas seperti checksum, menunggu WAL segment, fsync, dan verifikasi page checksum, tetapi ke depannya meskipun muncul fork, kepercayaan tetap harus dibangun ulang secara terpisah

Penghentian pemeliharaan dan status proyek

  • pgBackRest adalah alat backup dan pemulihan untuk PostgreSQL, tetapi saat ini sudah tidak lagi dipelihara
  • Proyek ini telah menghentikan pekerjaannya, dan menyatakan bahwa ke depan tidak akan lagi meluangkan waktu untuk bug fix, review PR, penanganan isu, maupun pengembangan fitur baru
  • Bahkan setelah bentuk sponsor dan hubungan kerja sebelumnya berakhir, upaya untuk tetap melanjutkan pemeliharaan masih dilakukan, tetapi peluang kerja dan sponsorship yang cukup untuk terus mempertahankan proyek ini tidak berhasil didapatkan
  • Daripada melanjutkan pemeliharaan secara tidak teratur atau tidak lengkap, dianggap lebih baik untuk mengakhirinya secara jelas
  • Ke depan seseorang mungkin saja melakukan fork, tetapi dalam kasus itu akan dianggap sebagai proyek baru, dan maintainer baru harus membangun kepercayaan secara terpisah

Fitur inti proyek

  • Menargetkan backup dan pemulihan yang dapat diskalakan hingga lingkungan PostgreSQL skala besar, dan versi stabil saat ini adalah v2.58.0
  • Dirancang untuk mengurangi biaya kompresi yang mudah menjadi bottleneck saat backup dengan memanfaatkan pemrosesan paralel dan metode kompresi seperti lz4 dan zstd
  • Mendukung backup full, differential, dan incremental, dan tidak hanya pada tingkat file tetapi juga block-level backup untuk menyalin hanya bagian yang berubah sehingga menghemat ruang penyimpanan
  • Backup yang terputus dapat dilanjutkan, dan integritas file yang sudah disalin diperiksa kembali dengan membandingkannya terhadap checksum dalam manifest
  • Dalam delta restore, file yang tidak ada di backup dihapus terlebih dahulu lalu checksum file yang tersisa dibandingkan, sehingga file yang cocok dibiarkan apa adanya dan hanya file yang diperlukan yang dipulihkan

Operasi jarak jauh dan desain repositori

  • Melalui protocol layer miliknya sendiri, backup, restore, dan pekerjaan arsip dapat dilakukan baik di lingkungan lokal maupun jarak jauh, dengan koneksi jarak jauh menggunakan TLS/SSH
  • Protocol layer yang sama juga menyediakan antarmuka kueri PostgreSQL, sehingga pekerjaan dapat dilakukan tanpa harus melakukan akses jarak jauh langsung ke PostgreSQL dan ini meningkatkan keamanan
  • Mendukung multiple repositories, sehingga repositori lokal untuk pemulihan cepat dan repositori jarak jauh untuk retensi jangka panjang serta redundansi dapat digunakan bersama
  • Repositori juga dapat ditempatkan di object store kompatibel S3, Azure, GCS, sehingga kapasitas dan masa retensi dapat diperluas secara signifikan
  • Repositori itu sendiri dapat dienkripsi, sehingga data backup tetap terlindungi di mana pun disimpan

Cara menjamin integritas dan konsistensi

  • Menghitung checksum untuk semua file dalam backup, lalu memeriksanya kembali saat restore atau verify
  • Setelah penyalinan file selesai, alat ini menunggu sampai semua WAL segment yang diperlukan untuk membuat backup berada dalam keadaan konsisten telah tiba di repositori
  • Dalam semua pekerjaan, fsync pada tingkat file dan direktori digunakan untuk memastikan durabilitas
  • Jika page checksum di PostgreSQL diaktifkan, maka pada backup full checksum halaman semua file diverifikasi, sedangkan pada backup differential dan incremental hanya file yang berubah yang diverifikasi
  • Bahkan jika verifikasi page checksum gagal, backup tidak dihentikan, tetapi peringatan tentang halaman mana yang gagal akan ditinggalkan sehingga page-level corruption dapat ditemukan lebih awal sebelum backup yang valid kedaluwarsa

Pemrosesan WAL dan optimasi performa pemulihan

  • Menyediakan perintah khusus WAL push/get, dan keduanya dirancang untuk mendukung pemrosesan paralel serta eksekusi asinkron agar waktu respons PostgreSQL tetap secepat mungkin
  • WAL push secara otomatis menghapus duplikasi jika WAL segment yang sama masuk beberapa kali, dan akan menghasilkan error jika isinya berbeda
  • WAL push asinkron menyerahkan pengiriman ke proses lain yang akan mengompresi WAL segment secara paralel, sehingga sangat penting terutama pada database dengan volume tulis yang sangat tinggi
  • WAL get asinkron mempertahankan WAL queue yang sudah didekompresi secara lokal agar dapat langsung disuplai sebelum replay, dan manfaatnya sangat besar terutama pada koneksi berlatensi tinggi atau penyimpanan seperti S3
  • Baik WAL push maupun get membandingkan versi PostgreSQL dan system identifier untuk memastikan kecocokan antara database dan repositori, sehingga kemungkinan salah konfigurasi lokasi arsip WAL dapat sangat dikurangi

Fleksibilitas operasional dan kompatibilitas

  • Kebijakan backup retention dan archive expiration dapat diatur terpisah berdasarkan unit full, differential, dan WAL sehingga dapat mencakup rentang periode yang diinginkan
  • Backup dapat disimpan dalam format PostgreSQL cluster apa adanya, dan jika kompresi dimatikan serta hard link diaktifkan, PostgreSQL cluster bahkan dapat dijalankan langsung di atas snapshot repositori
  • Pendekatan ini menguntungkan untuk terabyte-scale database yang membutuhkan waktu lama untuk restore tradisional
  • Mendukung tablespace sepenuhnya, dan saat restore setiap tablespace dapat dipindahkan ke lokasi berbeda atau diremap sekaligus ke satu lokasi
  • Link file dan direktori juga didukung, sehingga saat restore dimungkinkan mempertahankan lokasi asli, melakukan remap sebagian atau seluruhnya, atau memulihkannya sebagai file dan direktori biasa
  • Mendukung 10 versi PostgreSQL, termasuk 5 versi yang saat ini masih didukung dan 5 versi terbaru yang sudah EOL, agar tersedia waktu upgrade yang cukup longgar

Sumber referensi dan status sponsor

Bacaan terkait

2 komentar

 
xguru 13 hari lalu

Terkait hal ini, sudah ada pembaruan.

  • Setelah mengumumkan penghentian pemeliharaan pgBackRest, kotak masuk email membanjir
  • Banyak pesan dukungan yang datang
  • Berkat gabungan beberapa sponsor, pgBackRest akan menerima pendanaan sehingga proyek dapat terus dilanjutkan
  • Selain itu, satu orang maintainer tambahan akan direkrut untuk membagi beban kerja dan menjaga keberlanjutan proyek
  • Versi pgBackRest saat ini berfungsi normal, dan karena tidak ada bug serius atau masalah keamanan, tidak perlu segera mem-fork proyek ini
  • Sedang berupaya aktif untuk menghidupkan kembali pgBackRest
 
GN⁺ 20 hari lalu
Komentar Hacker News
  • Melihat tulisan penulis di LinkedIn, tampaknya waktu dan dedikasi yang ia curahkan selama 13 tahun untuk pgBackRest memang sangat besar, dan sekarang ia memutuskan untuk menghentikan pemeliharaan
    Memang ada dukungan perusahaan, tetapi ia tetap mencurahkan malam dan akhir pekan untuk ini, dan setelah Crunchy Data dijual, ia terus memeliharanya sambil mencari posisi agar bisa melanjutkan pekerjaan ini, tetapi tidak berhasil
    Demi mencari peluang yang lebih luas untuk nafkah, ia merasa tidak bisa lagi menyediakan waktu yang dibutuhkan untuk pemeliharaan, perbaikan bug, review PR, dan penanganan issue, sehingga repositori akan diarsipkan
  • Saya sudah lama menggunakan pgBackRest di proyek pribadi, sampai membuat panduan backup PostgreSQL untuk volume lokal dan penyimpanan cloud, jadi rasanya sayang kalau berakhir seperti ini
    Panduannya ada di https://github.com/freakynit/postgre-backup-and-restore-guide, dan saya benar-benar berterima kasih atas waktu serta usaha yang telah dicurahkan selama ini
    • Akhir-akhir ini, menurut saya ekspektasi terhadap AI juga membuat developer tertekan oleh tenggat yang lebih ketat sehingga waktu mereka makin sedikit
      Ditambah lagi, banyak orang membakar uang pada token, jadi dalam beberapa kasus cadangan dana dan waktu sama-sama berkurang
    • Saya berharap proyek seperti ini tidak terus menghilang karena gagal mendapatkan pendanaan, karena kesulitan nyata dalam OSS terasa terlalu besar
  • Di sini yang gagal bukan model open source itu sendiri, melainkan penulis yang tidak lagi bisa menemukan dukungan finansial sehingga memilih mengubah arah, dan menurut saya itu sepenuhnya masuk akal
    Jika ini adalah alat tingkat produk yang memberi nilai nyata di lingkungan komersial, bukan sekadar proyek hobi, maka jelas ada peluang bagi perusahaan profit untuk mengisi celah itu
    Hanya saja, pengguna harus menjadi pelanggan dan benar-benar membayar, karena tidak berkelanjutan jika terus mengirim laporan bug dan keluhan kepada maintainer gratisan
    Diperlukan solusi baru untuk keberlanjutan pendanaan FOSS, dan donasi saja tampaknya tidak cukup
    • Saya belajar bahwa di ekosistem apa pun, kalau saya ingin sesuatu tetap hidup, saya harus mendukungnya secara langsung
      Entah itu toko lingkungan maupun proyek open source, prinsipnya sama
    • Saya penasaran apakah penulis pernah mempertimbangkan cara untuk mengomersialkan ini
      Namun, tiap kontributor bisa saja memiliki hak cipta atas bagiannya, jadi tergantung ada tidaknya ACL dan yurisdiksinya, mungkin perlu penataan hak, termasuk kesepakatan seperti pembagian pendapatan
  • Menurut saya yang perlu lebih diperhatikan orang justru sisi akuisisi Crunchy Data
    Saat ada sponsor perusahaan, semuanya berjalan, tetapi setelah perusahaan dijual dan pemilik baru mengubah prioritas, alat infrastruktur dengan 3.8k star langsung menjadi tidak stabil, dan para pengguna ternyata tidak sadar bahwa sumber dana alat backup mereka bergantung pada strategi M&A pihak lain
    Karena itu, saya juga perlahan berpindah ke file yang dilacak dengan SQLite dan git
    Soalnya bahkan stack Postgres terkelola pun pada akhirnya berdiri di atas berbagai alat yang dipelihara orang-orang dengan kondisi pendanaan yang tidak kita ketahui
    • Ini belum benar-benar hilang, dan setidaknya untuk saat ini backup tidak langsung berhenti bekerja
      Hanya saja, gambaran besarnya tentang rapuhnya struktur pendanaan tetap benar
    • Tapi SQLite juga tidak sepenuhnya bebas dari risiko yang sama, jadi saya penasaran kenapa dianggap lebih aman
  • Kode sumbernya masih ada, jadi daripada hanya merasa sayang, masih ada pilihan untuk fork sendiri dan memeliharanya, atau membayar seseorang untuk menanganinya
    Sekalian, ada baiknya melihat lagi proyek-proyek dependensi yang tidak ingin kita kehilangan dan langsung mengatur dukungan dari sekarang
    • Saya rasa sikap ini benar
      Semua orang bilang sedih, tetapi kalau benar sedih, mungkin pertama-tama perlu ditanya apakah sedihnya sampai mau berdonasi
  • Sepanjang yang saya pahami tentang ekosistem ini, pgBackRest adalah solusi terbaik di ranah backup PostgreSQL
    Yang langka terutama karena ia tidak hanya serius soal backup, tetapi juga pemulihan dan verifikasi, dan saya pernah kena dampak besar di tempat kerja karena mengabaikan hal itu
    Cerita lengkapnya ada di https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
    Jadi ini terasa seperti kehilangan yang cukup besar
  • Cukup mengejutkan, dan saya selama ini menganggap ini praktis alat backup/pemulihan PG yang representatif
    Saya penasaran bagaimana perbandingannya dengan WAL-G atau Barman
    https://github.com/wal-g/wal-g
    https://github.com/EnterpriseDB/barman
    • Saya tidak bisa memberi perbandingan yang presisi, tetapi kami sudah lama memakai Barman dan sangat puas
      Setiap malam kami membuat DB nightly yang dipulihkan dengan Barman dan juga memakainya untuk pelatihan pengguna/pengujian, jadi backup terus diverifikasi apakah benar-benar rusak atau tidak, dan selama bertahun-tahun tidak ada masalah
    • Saya salah satu maintainer wal-g, dan menurut saya dari sisi fitur, tingkatnya cukup sebanding
      Setelah beberapa tahun tidak aktif, saya kembali ke ranah managed Postgres, dan berharap selain delta backup yang disediakan wal-g lewat perbandingan blok sendiri, ia juga mendukung pg17 incremental backup
      Dan mode daemon memang sebaiknya dipakai
      Sayang kalau alat pesaing menghilang, tetapi area ini masih punya banyak ruang untuk diperbaiki, dan ketika Postgres ingin berjalan di sistem tanpa overcommit, ada sisi di mana C lebih baik daripada Golang
    • Dulu kami memakai WAL-E, dan sekarang penerusnya yaitu WAL-G, dengan hasil yang memuaskan
      Saat mengevaluasi sekitar 9 tahun lalu, pendekatan ini lebih menarik daripada pgBackRest karena karakteristik streaming PITR
    • Saya paham kenapa ini dianggap alat representatif, tetapi situasi seperti https://xkcd.com/2347/ juga terbayang
  • Saya sudah puas memakai pgBackRest pada DB produksi 2TB, dan kebetulan minggu ini saya berencana memasangnya juga pada DB 8TB
    Jadi sekarang saya penasaran alternatif terdekatnya itu wal-g, barman, atau databasus
    Saya memang bilang cuma pura-pura jadi DBA, tetapi kenyataannya pilihan ini cukup penting
    • Saya pernah memakai Barman untuk DB 30TB+, dan tidak punya keluhan berarti
      Sebagai catatan, saya seorang DBRE
    • Kalau Anda membackup Postgres produksi multi-terabyte, itu bukan level pura-pura jadi DBA, melainkan memang sudah melakukannya dengan serius
    • Jika konfigurasi Anda menaruh backup di penyimpanan cloud, maka Barman dengan hook scripts tampaknya adalah alternatif yang paling dekat
      Dokumentasinya ada di 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 juga terlihat bagus, meski saya belum memverifikasinya sendiri
    • Saya juga penasaran apakah ada yang pernah menaruh standby di atas ZFS atau filesystem lain yang mendukung snapshot lalu membackup dari sana
    • Saya bahkan belum pernah memakai pgBackRest, tetapi tepat 2 jam yang lalu saya mulai memasangnya ke sebuah proyek, dan setelah selesai membaca README, ternyata sudah ada pembaruan ini
  • pgBackRest termasuk salah satu teknologi backup PostgreSQL yang paling serbaguna, dan menurut pengalaman saya, produk lain belum benar-benar bisa menyamai sampai sejauh ini
    Karena itu kejadian ini makin disayangkan, dan menyamai kesetaraan fitur alat hebat ini sepertinya tidak akan mudah
    Kalau bisa, semoga ini keputusan yang masih bisa dibalik, atau kalau tidak, mudah-mudahan ada jalan agar proyek PostgreSQL menyerapnya ke contrib
  • Untuk saat ini masih bisa terus dipakai, jadi silakan tetap digunakan
    Penulis pun kemungkinan lebih berharap orang tetap memakainya sampai benar-benar tidak berfungsi lagi, daripada langsung membuangnya sekarang
    • Dan semoga saat itu ada seseorang yang mau maju sebagai maintainer baru
      Saya tidak tahu apakah perlu fork, atau masih bisa diteruskan dengan masuk sebagai kontributor ke repositori yang ada