pgbackrest/pgbackrest

 (github.com/pgbackrest)
3 poin oleh GN⁺ 12 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Sebagai alat backup dan pemulihan untuk PostgreSQL yang dirancang agar dapat diskalakan hingga lingkungan berskala besar, proyek ini kini berstatus tidak lagi dipelihara
  • Perbaikan bug, review PR, penanganan issue, dan pengembangan fitur baru semuanya telah dihentikan, dan dipilih untuk berhenti secara jelas daripada mempertahankannya secara tidak teratur
  • Mendukung backup penuh, differential, incremental, serta block-level backup, melanjutkan pekerjaan yang terhenti, 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 serta object store yang kompatibel dengan 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, sekalipun ada fork, kepercayaan harus dibangun kembali 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 menghabiskan waktu untuk perbaikan bug, review PR, penanganan issue, atau pengembangan fitur baru
  • Setelah bentuk sponsor dan hubungan kerja sebelumnya berakhir, upaya untuk tetap melanjutkan pemeliharaan sempat dilakukan, tetapi tidak berhasil memperoleh peluang kerja dan sponsorship yang cukup untuk terus mempertahankan proyek
  • Daripada melanjutkan pemeliharaan secara tidak teratur atau tidak lengkap, proyek ini menilai bahwa mengakhirinya dengan jelas adalah pilihan yang lebih baik
  • Di masa mendatang seseorang mungkin saja membuat fork, tetapi dalam hal itu proyek tersebut akan dianggap sebagai proyek baru, dan maintainer baru harus membangun kepercayaan mereka sendiri secara terpisah

Fitur inti proyek

  • Menargetkan backup dan pemulihan yang dapat diskalakan hingga lingkungan PostgreSQL berskala besar, dengan 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 penuh, differential, dan incremental, serta menghemat ruang penyimpanan dengan menyalin hanya bagian yang berubah melalui block-level backup, bukan hanya pada tingkat file
  • Dapat melanjutkan backup yang terhenti, lalu memeriksa kembali integritas file yang sudah disalin dengan membandingkannya dengan checksum dalam manifest
  • Dalam delta restore, file yang tidak ada dalam backup akan 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, pemulihan, dan pekerjaan arsip dapat dilakukan baik di lingkungan lokal maupun jarak jauh, dan koneksi jarak jauh menggunakan TLS/SSH
  • Protocol layer yang sama juga menyediakan antarmuka kueri PostgreSQL, sehingga pekerjaan dapat dilakukan tanpa harus terhubung jarak jauh langsung ke PostgreSQL, yang meningkatkan keamanan
  • Mendukung multiple repositories, sehingga repositori lokal untuk pemulihan cepat dan repositori jarak jauh untuk retensi jangka panjang serta redundansi dapat digunakan bersamaan
  • Repositori juga dapat ditempatkan pada object store yang kompatibel dengan S3, Azure, dan GCS, sehingga kapasitas dan periode 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, sistem menunggu hingga semua WAL segment yang diperlukan untuk membuat backup dalam keadaan konsisten tiba di repositori
  • Menggunakan fsync pada tingkat file dan direktori di semua pekerjaan untuk memastikan durabilitas
  • Jika page checksum diaktifkan di PostgreSQL, maka checksum halaman dari semua file diverifikasi pada backup penuh, sedangkan pada backup differential dan incremental hanya file yang berubah yang diverifikasi
  • Meskipun verifikasi page checksum gagal, backup tidak dihentikan, tetapi peringatan tentang halaman mana yang gagal akan dicatat agar 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 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 sehingga WAL segment dapat dikompresi secara paralel, yang sangat penting terutama pada database dengan volume tulis sangat tinggi
  • WAL get asinkron mempertahankan queue WAL yang sudah didekompresi secara lokal agar dapat langsung disuplai sebelum replay, yang sangat menguntungkan terutama pada koneksi berlatensi tinggi atau penyimpanan seperti S3
  • Baik WAL push maupun get membandingkan versi PostgreSQL dan system identifier untuk memastikan database dan repositori saling cocok, sehingga kemungkinan salah konfigurasi lokasi WAL archive dapat sangat dikurangi

Fleksibilitas operasional dan kompatibilitas

  • Kebijakan backup retention dan archive expiration dapat diatur terpisah berdasarkan full, differential, dan WAL sehingga dapat mencakup rentang periode yang diinginkan
  • Backup dapat disimpan dalam format cluster PostgreSQL apa adanya, dan jika kompresi dimatikan serta hard link diaktifkan, cluster PostgreSQL bahkan dapat dijalankan langsung di atas snapshot repositori
  • Pendekatan ini menguntungkan pada database berskala terabyte ketika restore tradisional memerlukan waktu lama
  • Mendukung tablespace sepenuhnya, dan saat restore setiap tablespace dapat dipindahkan ke lokasi lain atau di-remap secara massal ke satu lokasi
  • Juga mendukung link file dan direktori, sehingga saat restore dimungkinkan untuk mempertahankan lokasi asli, melakukan remap sebagian atau seluruhnya, atau memulihkannya sebagai file dan direktori biasa
  • Mendukung 10 versi PostgreSQL, mencakup 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

1 komentar

 
GN⁺ 12 jam 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