Backup, Bukan Burnout: Apa yang Kami Luncurkan di Postgresus 2.0 (dan Apa yang Kami Hapus)

\ Sudah 6 bulan sejak rilis pertama Postgresus. Selama waktu ini, proyek ini menerima 247 commit, fitur baru, serta ~2,8k bintang di GitHub dan ~42k unduhan dari Docker Hub. Komunitas proyek juga telah berkembang, sekarang ada 13 kontributor dan 90 orang di grup Telegram.

Dalam artikel ini saya akan membahas:

• apa yang berubah dalam proyek selama enam bulan;
• fitur baru apa saja yang muncul
• rencana apa selanjutnya.

\

Apa itu Postgresus?

Bagi yang baru mendengar tentang proyek ini: Postgresus adalah alat backup PostgreSQL open source dengan UI. Ini menjalankan backup terjadwal dari beberapa database, menyimpannya secara lokal atau ke penyimpanan eksternal, dan memberi tahu Anda ketika backup selesai atau gagal.

Proyek ini di-deploy dengan satu perintah di Docker. Dapat diinstal melalui shell script, perintah Docker, docker-compose.yml dan sekarang melalui Helm untuk Kubernetes. Lebih lanjut tentang metode instalasi.

Selain fitur utama "membuat backup", proyek ini dapat:

• Menyimpan backup secara lokal, di S3, CloudFlare R2, Google Drive, Azure Blob Storage dan NAS. Detail lebih lanjut di sini.
• Mengirim notifikasi status ke Slack, Discord, Telegram, MS Teams, melalui email dan ke webhook yang dapat dikonfigurasi. Detail lebih lanjut di sini.
• Memisahkan database berdasarkan workspace, memberikan akses ke pengguna lain dan menyimpan log audit. Detail lebih lanjut di sini.
• Mengenkripsi backup dan kredensial. Detail lebih lanjut di sini.
• Bekerja dengan database yang dihosting sendiri dan database yang dikelola cloud.

Website - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (akan menghargai bintang ⭐️)

Antarmuka proyek terlihat seperti ini:

Video ikhtisar: https://www.youtube.com/watch?v=1qsAnijJfJE

Bagi yang ingin berpartisipasi dalam pengembangan, ada halaman terpisah dalam dokumentasi. Jika seseorang ingin membantu proyek tetapi tidak ingin menulis kode — cukup beritahu kolega dan teman Anda tentang proyek ini! Ini juga bantuan besar dan kontribusi untuk proyek.

Saya tahu cara mengembangkan, tetapi mempromosikan bahkan proyek open source cukup sulit. Proyek ini mendapatkan pengakuan berkat mereka yang membuat ulasan video dan berbicara tentang proyek di media sosial. Terima kasih!

Fitur baru yang muncul di versi 2.0

Banyak yang berubah selama enam bulan ini. Proyek telah ditingkatkan dalam empat arah:

• memperluas fungsionalitas dasar;
• meningkatkan UX;
• muncul kemampuan baru untuk tim (DBA, DevOps, tim, perusahaan);
• meningkatkan perlindungan dan enkripsi untuk memenuhi persyaratan perusahaan.

Mari kita bahas satu per satu.

1) Pemeriksaan kesehatan database

Selain backup, Postgresus sekarang memantau kesehatan database: menunjukkan uptime dan memberi peringatan jika database tidak tersedia.

Pemeriksaan kesehatan dapat dinonaktifkan dan dikonfigurasi.

Jika database tidak tersedia — sistem akan mengirimkan notifikasi tentang hal itu.

2) Sumber baru untuk menyimpan backup dan mengirim notifikasi

Awalnya Postgresus hanya dapat menyimpan backup secara lokal dan di S3. Google Drive, CloudFlare R2, Azure Blob Storage dan NAS telah ditambahkan. Rencana termasuk menambahkan FTP dan kemungkinan SFTP dan NFS.

Untuk notifikasi, awalnya proyek memiliki Telegram dan email (SMTP). Sekarang Slack, Discord, MS Teams dan webhook juga didukung. Selain itu, webhook sekarang dapat dikonfigurasi secara fleksibel untuk terhubung ke platform yang berbeda:

3) Manajemen workspace dan pengguna

Sebelumnya sistem hanya memiliki satu pengguna (administrator), dan database bersifat global untuk seluruh sistem. Sekarang Postgresus mendukung pembuatan workspace untuk memisahkan database dan menambahkan pengguna ke workspace. Dengan pemisahan peran:

• hanya lihat (dapat melihat riwayat backup, mengunduh file backup);
• edit (dapat menambah\menghapus\memodifikasi database selain membaca).

Akibatnya, Anda sekarang dapat memisahkan database:

• database klien X;
• database startup Y;
• database tim Z;

Tim DBA dan perusahaan outsourcing besar mulai menggunakan Postgresus, sehingga ini menjadi fitur penting. Ini membuat proyek berguna tidak hanya untuk pengembang individu, DevOps atau DBA, tetapi untuk seluruh tim dan perusahaan.

Log audit juga muncul:

Jika seseorang memutuskan untuk menghapus semua database atau karena alasan tertentu mengunduh semua backup dari semua database — ini akan terlihat 🙃

4) Enkripsi dan perlindungan

Dalam versi pertama, jujur saja, saya tidak punya waktu untuk keamanan. Saya menyimpan semua file backup secara lokal, tidak ada yang memiliki akses ke mereka, dan proyek saya tidak terlalu rahasia.

Tetapi ketika Postgresus menjadi open source, saya cepat belajar bahwa tim sering menyimpan backup ke bucket S3 bersama dan tidak ingin orang lain membacanya. Kata sandi database juga tidak boleh disimpan di DB Postgresus sendiri, karena banyak orang memiliki akses ke servernya. ~~Dan ada sedikit ketidakpercayaan satu sama lain.~~ Hanya tidak mengekspos rahasia melalui API tidak lagi cukup.

Jadi, enkripsi dan keamanan seluruh proyek menjadi prioritas utama untuk Postgresus. Perlindungan sekarang bekerja pada tiga tingkat, dan ada halaman dokumentasi khusus untuk ini.

1) Enkripsi semua kata sandi dan rahasia

Semua kata sandi database, token Slack dan kredensial S3 disimpan terenkripsi di database Postgresus. Mereka didekripsi hanya ketika diperlukan. Kunci rahasia disimpan dalam file terpisah dari DB, jadi bahkan jika seseorang meretas DB Postgresus (yang tidak terekspos secara eksternal) — mereka tetap tidak bisa membaca apa pun. Enkripsi menggunakan AES-256-GCM.

2) Enkripsi file backup

File backup sekarang juga dienkripsi (opsional, tetapi enkripsi diaktifkan secara default). Jika Anda kehilangan file atau menyimpannya di S3 publik — itu tidak terlalu menakutkan lagi.

Enkripsi menggunakan salt dan vektor inisialisasi unik. Ini mencegah penyerang menemukan pola untuk menebak kunci enkripsi, bahkan jika mereka mencuri semua file backup Anda.

Enkripsi dilakukan dalam mode streaming, AES-256-GCM juga digunakan di sini.

3) Menggunakan pengguna hanya baca untuk backup

Terlepas dari dua poin pertama, tidak ada metode perlindungan 100%. Masih ada kemungkinan kecil bahwa:

• server Anda akan diretas sepenuhnya, mereka akan mendapatkan kunci rahasia dan alamat IP yang sah untuk mengakses database;
• peretas akan entah bagaimana mendekripsi kata sandi di DB internal Postgresus dan mengetahui kata sandi database Anda;
• atau, lebih buruk lagi, bukan peretas tetapi seseorang dari dalam;
• dan mereka akan merusak database Anda, setelah sebelumnya menghapus backup.

Jadi Postgresus harus membantu pengguna meminimalkan kerusakan. Probabilitas peretasan semacam itu mungkin mendekati nol, tetapi itu bukan penghiburan jika Anda adalah orang yang mengalaminya.

Sekarang ketika Anda menambahkan pengguna database dengan izin tulis ke Postgresus, sistem menawarkan untuk secara otomatis membuat pengguna hanya baca dan menjalankan backup melaluinya. Orang jauh lebih mungkin membuat peran hanya-baca ketika hanya membutuhkan satu klik daripada mengaturnya secara manual di database.

Beginilah cara Postgresus menawarkan:

Menawarkan dengan sangat gigih:

Dengan pendekatan ini, bahkan jika server Postgresus Anda diretas, semuanya didekripsi dan penyerang mendapatkan akses ke DB Anda — mereka setidaknya tidak akan dapat merusak database. Mengetahui bahwa tidak semuanya hilang adalah penghiburan yang cukup baik.

5) Kompresi secara default, yang paling optimal

Versi pertama Postgresus menawarkan semua algoritma kompresi yang didukung PostgreSQL: gzip, lz4 dan zstd, dengan level kompresi dari 1 hingga 9. Jujur, saya tidak benar-benar mengerti mengapa seseorang membutuhkan semua opsi ini. Saya hanya memilih gzip dengan level 5 sebagai apa yang tampaknya jalan tengah yang masuk akal.

Tetapi setelah proyek menjadi open source, saya harus benar-benar meneliti hal ini. Jadi saya menjalankan 21 backup dalam semua kombinasi yang mungkin dan menemukan trade-off terbaik antara kecepatan dan ukuran.

Jadi sekarang secara default untuk semua backup zstd dengan level kompresi 5 diatur, jika versi PostgreSQL adalah 16 dan lebih tinggi. Jika lebih rendah — masih gzip (ngomong-ngomong, terima kasih lagi kepada kontributor untuk dukungan PG 12). Berikut zstd 5 dibandingkan dengan gzip 5 (ada di bagian bawah):

Rata-rata, backup dikompresi ~8 kali relatif terhadap ukuran database sebenarnya.

6) Dukungan Kubernetes Helm

Yang ini cepat — kami menambahkan dukungan k8s native dengan instalasi Helm. Tim yang menjalankan k8s di cloud sekarang dapat men-deploy Postgresus dengan lebih mudah. Tiga kontributor membantu dengan fitur ini.

7) Tema gelap

Saya sebenarnya bukan penggemar tema gelap. Tetapi ada banyak permintaan, jadi saya menambahkan satu (~~terima kasih Claude untuk bantuan dan mata desainer~~). Mengejutkan, ternyata lebih baik dari tema terang dan menjadi default. Saya bahkan mendesain ulang situs web dari terang ke gelap — terlihat sangat bagus.

Sebelum:

Setelah:

8) Menghilangkan backup inkremental dan PITR (Point In Time Recovery)

Pertama, beberapa konteks:

• Backup logis — adalah ketika PostgreSQL sendiri mengekspor datanya (ke file atau kelompok file).
• Backup fisik — adalah ketika kita terhubung ke hard drive PostgreSQL dan membuat salinan file-filenya.
• Backup inkremental dengan dukungan PITR — adalah backup fisik + log perubahan (WAL), disalin dari disk atau melalui protokol replikasi.

Saya percaya Postgresus pada akhirnya harus mendukung backup inkremental. Lagi pula, itulah yang dilakukan alat-alat serius! Bahkan ChatGPT mengatakan alat serius dapat memulihkan dengan presisi hingga detik dan transaksi.

Jadi saya mulai bekerja pada hal itu. Tetapi kemudian kenyataan menghantam:

• Sangat sulit membuatnya nyaman dalam hal UX dan DevEx. Karena Anda perlu terhubung secara fisik ke disk dengan DB, atau mengatur replikasi.

Untuk pemulihan — tidak ada pilihan untuk tidak terhubung ke disk dengan database. Untuk memulihkan dari backup inkremental, alat backup hanya memulihkan folder pgdata (lebih tepatnya, sebagian darinya).

Jika database benar-benar besar, misalnya, beberapa TB dan lebih — penyesuaian dalam konfigurasi diperlukan. Di sini UI lebih merupakan hambatan daripada bantuan.

• Sebagian besar cloud (AWS, Google, Selectel) tidak akan bekerja dengan backup inkremental eksternal, jika mereka memerlukan akses disk. Secara teori, dengan beberapa solusi, melalui replikasi — mereka akan. Tetapi memulihkan dari backup semacam itu ke cloud terkelola tetap tidak akan berfungsi.
• Semua cloud menyediakan backup inkremental secara default. Secara umum, ini adalah salah satu alasan mengapa mereka berbayar. Dan bahkan mereka biasanya tidak memungkinkan pemulihan detik demi detik atau ke momen transaksi tertentu. Dan jika Anda tidak di cloud — bahkan lebih tidak mungkin bahwa proyek Anda cukup kritis untuk memerlukan presisi seperti itu.

Oleh karena itu, jika Postgresus membuat backup dari DB terkelola — cukup melakukannya sekitar seminggu sekali. Hanya untuk berjaga-jaga jika terjadi keadaan darurat yang tidak terduga atau jika cloud tidak memungkinkan menyimpan backup cukup lama. Jika tidak, andalkan backup inkremental cloud sendiri.

• Untuk sebagian besar proyek, backup inkremental tidak benar-benar diperlukan. Untuk database kecil, granularitas antara backup satu jam sudah cukup, jika diperlukan sering. Untuk yang besar — setidaknya sekali sehari. Ini cukup untuk 99% proyek untuk menemukan data yang hilang atau memulihkan sepenuhnya. Kebutuhan ini sepenuhnya tercakup oleh backup logis.

Tetapi jika Anda adalah bank atau pengembang DB terkelola, Anda benar-benar membutuhkan konfigurasi backup terbaik untuk puluhan dan ratusan terabyte data Anda. Di sini Postgresus tidak akan pernah mengungguli backup fisik dari WAL-G atau pgBackRest dalam hal kenyamanan konsol dan efisiensi untuk DB dengan volume dalam TB dan lebih. Tetapi, menurut pendapat saya, ini sudah merupakan alat khusus untuk tugas-tugas seperti itu, dibuat oleh jenius dan pemelihara PostgreSQL itu sendiri.

Menurut pendapat saya, backup inkremental benar-benar diperlukan dalam dua kasus:

• Di masa lalu, ketika tidak ada pilihan database terkelola cloud dan proyek besar memerlukan hosting semuanya sendiri. Sekarang bank, marketplace, dan telekomunikasi yang sama memiliki cloud internal dengan PITR secara default.
• Anda adalah cloud terkelola. Tetapi di sini tugasnya jauh lebih kompleks daripada sekadar membuat backup dan memulihkan darinya.

Mempertimbangkan semua ini, saya membuat keputusan yang disengaja untuk menghentikan pengembangan backup inkremental. Sebagai gantinya, saya fokus pada membuat backup logis yang nyaman, andal, dan praktis untuk penggunaan sehari-hari oleh pengembang, DevOps, DBA, dan perusahaan.

9) Banyak peningkatan kecil

Poin-poin di atas jauh dari semuanya. 80% pekerjaan biasanya tidak terlihat. Yang terlintas di pikiran saya, berikut daftar singkat:

• Buffering dan optimasi RAM. Postgresus tidak lagi mencoba mem-buffer semua yang dikirim pg_dump sambil menunggu S3 mengejar (mengunduh dari database biasanya lebih cepat daripada mengunggah ke cloud). Penggunaan RAM sekarang dibatasi hingga 32 MB per backup paralel.
• Berbagai peningkatan stabilitas dan perbaikan bug kecil.
• Menambahkan SMTP tanpa nama pengguna dan tanpa kata sandi. Saya bahkan tidak tahu itu terjadi…
• Menambahkan topik untuk mengirim notifikasi ke grup Telegram.
• Dokumentasi muncul!
• Dukungan PostgreSQL 12.

Dan banyak lagi.

Apa yang tidak berhasil?

Tentu saja, tidak semuanya berhasil dan beberapa hal harus dihentikan. Saya membangun Postgresus di waktu luang saya, yang hampir tidak ada. Jadi saya tidak bisa menyebar terlalu tipis atau memperumit UX dengan fitur yang tidak perlu. Terlalu banyak fitur juga buruk.

1) Pemantauan sumber daya database penuh

Saya ingin menjadikan Postgresus juga sebagai alat pemantauan PostgreSQL. Termasuk sumber daya sistem server yang menjalankan PostgreSQL:

• CPU
• RAM
• ROM
• Kecepatan IO dan beban

Saya bahkan membuat dasar untuk mengumpulkan metrik (apa pun) dan template untuk grafik:

Ternyata PostgreSQL hanya mengekspos penggunaan RAM dan metrik IO secara default.

Pemantauan sumber daya lain memerlukan ekstensi. Tetapi tidak setiap database dapat menginstal ekstensi yang saya butuhkan, jadi saya hanya bisa mengumpulkan metrik parsial. Kemudian saya menemukan bahwa database cloud sering tidak mengizinkan instalasi ekstensi sama sekali.

Kemudian saya menyadari metrik harus disimpan di VictoriaMetrics atau setidaknya TimescaleDB, bukan di PostgreSQL Postgresus sendiri, yang akan memperumit build image.

Pada akhirnya, fitur yang tidak esensial ini akan menambahkan:

• kompleksitas kode yang signifikan, artinya pemeliharaan lebih sulit;
• lebih banyak persyaratan build image (komponen tambahan);
• UX yang rumit (seperti yang saya katakan, terlalu banyak fitur itu buruk);
• ~~positioning yang tidak jelas: apakah kita alat backup, alat pemantauan, atau mencoba melakukan semuanya?~~

Jadi saya menghentikan pemantauan sumber daya dan fokus pada menjadikan Postgresus alat backup terbaik yang bisa.

2) Konsol SQL

Saya juga ingin menambahkan konsol SQL. Karena Postgresus sudah terhubung ke DB, mengapa tidak menjalankan kueri langsung darinya? Itu akan nyaman — tidak perlu membuka PgAdmin, DataGrip, atau DBeaver setiap kali.

Saya tidak pernah menemukan waktu untuk mengerjakannya, hanya merencanakan. Satu kontributor mulai mengerjakan fitur tersebut dan membuat PR. Tetapi seperti yang diharapkan dengan fitur kompleks, banyak persyaratan dan kasus edge muncul:

• perlu menambahkan dukungan sintaks SQL;
• menambahkan autocomplete dan petunjuk;
• membuat lazy loading sehingga bahkan 100MB baris tidak datang ke browser;
• menambahkan setidaknya beberapa ekspor ke CSV dan XLSX.

Itu pada dasarnya proyek penuh tersendiri, bukan hanya satu tab.

Kami memutuskan untuk menghentikan fitur dan menghemat usaha. Ini ternyata keputusan yang tepat, karena kami menambahkan peran hanya baca yang tidak mengizinkan INSERT, UPDATE dan DELETE bagaimanapun.

Kesimpulan

Itulah perjalanan yang telah dilakukan Postgresus dalam enam bulan. Ini berkembang dari proyek niche menjadi alat tingkat perusahaan yang membantu baik pengembang individu maupun seluruh tim DBA (saya terkejut mengetahui ini hanya ~2 bulan setelah rilis pertama, ngomong-ngomong). Saya benar-benar senang bahwa ribuan proyek dan pengguna mengandalkan Postgresus.

Proyek ini tidak berhenti di sini. Tujuan saya sekarang adalah menjadikan Postgresus alat backup PostgreSQL yang paling nyaman di dunia. Ada backlog besar fitur dan peningkatan yang datang secara bertahap.

Prioritas utama saya tetap:

• keamanan proyek — ini penting, tanpanya semua yang lain tidak masuk akal;
• UX yang nyaman dalam hal menggunakan proyek itu sendiri dan tidak berlebihan fitur (kita melakukan satu tugas, tetapi sangat baik);
• UX yang nyaman dalam hal deployment: sehingga semuanya di-deploy dengan satu perintah dan tidak ada yang perlu dikonfigurasi dari awal;
• keterbukaan proyek — sepenuhnya open source dan gratis untuk setiap orang atau perusahaan.

Jika Anda menyukai proyek ini atau menganggapnya berguna — saya akan menghargai bintang di GitHub atau membagikannya dengan teman-teman ❤️

\