Pertanyaan umum

Temukan jawaban atas pertanyaan yang paling sering diajukan tentang Databasus, termasuk instalasi, konfigurasi, dan strategi backup.

Mengapa Databasus tidak memakai format dump SQL mentah untuk backup logis PostgreSQL?

Untuk backup logis, Databasus memakai pg_dump dalam format custom dengan kompresi zstd level 5, bukan format SQL biasa, karena memberikan keseimbangan paling efisien antara:

  • Kecepatan pembuatan backup
  • Kecepatan restore
  • Kompresi ukuran file (hingga 20x lebih kecil daripada format SQL biasa)

Keputusan ini diambil setelah pengujian dan benchmark menyeluruh atas berbagai format backup dan metode kompresi PostgreSQL. Baca lebih lanjut tentang pengujiannya di Backup PostgreSQL: perbandingan kecepatan pg_dump dalam berbagai format dan kompresi.

Databasus tidak akan menyediakan format dump SQL mentah karena:

  • terlalu banyak pilihan memperburuk pengalaman penggunaan;
  • membuat kode lebih sulit dipelihara;
  • format dump saat ini cocok untuk 99% kasus

Di mana Databasus diinstal jika memakai script .sh?

Databasus diinstal di direktori /opt/databasus/.

Bagaimana backup fisik dan PITR (Point-in-Time Recovery) bekerja?

Databasus menjalankan backup fisik secara remote dari host-nya sendiri, terhubung ke PostgreSQL melalui protokol replikasi standar, sehingga tidak perlu menginstal apa pun di server database. Jika database berada di jaringan tertutup, Databasus bisa menjangkaunya melalui tunnel SSH ke host internal atau bastion, jadi database tidak perlu dibuka ke publik.

Mengapa ini sekarang bisa dilakukan: selama bertahun-tahun, alat seperti pgBackRest dan WAL-G harus membuat engine backup inkremental tingkat blok sendiri karena PostgreSQL belum menyediakannya secara native. Ini berubah di PostgreSQL 17, ketika fitur tersebut dikembangkan oleh Robert Haas dengan bantuan David Steele, pembuat pgBackRest. PostgreSQL kini menyediakan backup inkremental tingkat blok native di sisi server (pg_basebackup --incremental dan summarize_wal), jadi Databasus memanfaatkannya, bukan membuat ulang.

Cara kerja backup:

  • Backup penuh dibuat dengan pg_basebackup dan dialirkan langsung ke Databasus
  • Backup inkremental tingkat blok memakai pg_basebackup --incremental. Ringkasan WAL di sisi server PostgreSQL 17 (summarize_wal = on) melacak perubahan sehingga hanya blok yang berubah yang ditransfer
  • WAL dialirkan terus-menerus melalui pg_receivewal untuk menjaga rangkaian pemulihan tetap lengkap di antara backup
  • Backup fisik memerlukan PostgreSQL 17 atau lebih baru; pada versi lebih lama, gunakan backup logis pg_dump

Cara kerja restore:

  • pg_combinebackup menyusun kembali direktori data yang bisa dijalankan dari backup penuh dan rangkaian backup inkrementalnya
  • PostgreSQL kemudian memutar ulang WAL hingga waktu target pilihan kamu, sehingga pemulihan bisa dilakukan ke detik mana pun di antara backup
  • Setelah PostgreSQL dijalankan, proses pemulihan diselesaikan, server beralih menjadi primary, dan operasi normal dilanjutkan

Kamu tidak perlu melakukannya secara manual. Antarmuka Databasus memberi petunjuk langkah demi langkah untuk restore ke host atau database Docker, baik melalui script siap pakai maupun dengan mengunduh backup secara manual. Kami menyiapkan script agar restore cukup dengan satu perintah, tetapi kamu juga bisa menyusun sendiri rangkaian backup penuh, inkremental, dan WAL. Backup inkremental dan WAL juga opsional: kamu bisa hanya membuat backup penuh tanpa backup inkremental, dan WAL tidak wajib.

Alasan kami memakai backup native PG 17:

  • Memanfaatkan mekanisme backup PostgreSQL sendiri alih-alih membuat ulang, sehingga bagian internalnya sudah teruji dengan ribuan pengujian dan kasus khusus
  • Menjaga kehilangan data tetap mendekati nol, dengan restore ke detik mana pun di antara backup

Mengapa Databasus meninggalkan backup berbasis agen?

Versi Databasus sebelumnya menyediakan agen backup: binary yang berjalan di host database untuk melakukan streaming WAL dan membuat backup fisik secara lokal. Implementasi pertama itu ternyata keliru, dan kami menghapusnya. Backup fisik kini berjalan secara remote dari host Databasus, seperti dijelaskan di atas.

Mengapa pendekatan agen tidak tepat:

  • Implementasinya terlalu sederhana, hanya menyalin WAL di atas backup penuh, sehingga RTO menjadi lama
  • Pengguna harus mengatur Databasus sekaligus agen terpisah, padahal menjalankan semuanya secara remote dari satu tempat jauh lebih sederhana
  • Karena agen berada di luar sistem utama, semua kasus pengujian sulit dicakup
  • Sebenarnya hanya satu masalah yang diselesaikan agen: menjangkau database yang tidak bisa diakses dari luar. Untuk 99% pengguna, hal itu sudah ditangani dengan menjalankan Databasus di jaringan privat atau terhubung melalui SSH. Agen jadi mengulang solusi yang sudah ada dan membuat masalah sederhana jauh lebih rumit dari yang diperlukan
  • Agen tidak bisa berjalan di database terkelola seperti RDS dan Cloud SQL, yang melarang instalasi di host tetapi sudah menyediakan protokol replikasi, sehingga jalur remote tetap diperlukan
  • Ada banyak kasus khusus yang menyulitkan: koneksi terputus, pengelolaan pembaruan agen, dan pengumpulan log dari proses terpisah. Semakin sedikit komponen yang perlu dikelola, semakin andal sistem dalam penggunaan sehari-hari

Kami memastikan backup yang sudah ada tetap aman. Jika kamu memperbarui dari versi yang masih memiliki backup agen, Databasus tidak melakukannya diam-diam. Databasus memperingatkan perubahan dan memberi pilihan untuk tetap memakai versi 3.42.0 yang didukung atau menghapus sendiri backup agen lama sebelum memperbarui. Implementasi berbasis agen tetap tersedia hingga versi 3.42.0 dan akan terus bekerja untuk waktu yang lama, jadi tidak ada yang rusak.

Bagaimana AI digunakan dalam pengembangan Databasus?

AI membantu kami mengembangkan Databasus, dari perencanaan dan implementasi hingga pengujian dan dokumentasi. Manusia menentukan arah dan mengambil keputusan akhir. Pengembang membaca setiap baris kode sebelum perubahan digabungkan.

Kami menggunakan pengembangan berbasis spesifikasi (SDD) dengan OpenSpec untuk menyepakati perilaku sebelum implementasi.

Review independen pada setiap tahap

Hook otomatis memulai sesi peninjau terpisah dengan akses hanya baca ke repositori. Setiap agen memeriksa kode terkait dan memberikan temuannya sendiri. Agen pelaksana tidak dapat menyetujui pekerjaannya sendiri.

Review dimulai sebelum implementasi. Agen perencanaan terpisah mencari solusi yang lebih sederhana, memeriksa nama yang diusulkan, dan menilai desain. Mereka juga memeriksa kesesuaian persyaratan dengan tugas verifikasi.

  • Peninjau kode: Mencari bug, kasus batas yang terlewat, penanganan error yang salah, kondisi balapan, kebocoran sumber daya, dan masalah keamanan.
  • Peninjau persyaratan: Menelusuri implementasi dan pengujian untuk setiap persyaratan. Memeriksa apakah pengujian benar-benar membuktikan perilaku yang dijanjikan.
  • Peninjau arsitektur: Memeriksa batas modul, arah dependensi, kepemilikan data, migrasi, dan aturan API.
  • Peninjau struktur kode: Memeriksa nama, tanggung jawab file dan fungsi, komentar, serta keterbacaan.
  • Peninjau pengujian: Menilai apakah pengujian dapat mendeteksi perilaku yang hilang atau regresi. Juga memeriksa penantian kondisi, pembersihan, dan bukti verifikasi.
  • Peninjau dokumentasi dan tugas: Memeriksa kesesuaian dokumentasi dengan kode, penyelesaian tugas, dan bukti pemeriksaan yang dilaporkan.

Review implementasi lengkap berjalan paralel. Setiap spesifikasi yang berubah memiliki peninjau persyaratannya sendiri. Arsitektur, pengujian, dan dokumentasi memiliki peninjau terpisah. Jadi, perubahan pada dua spesifikasi mendapat lima agen review lengkap.

Temuan yang menghalangi penerimaan menghentikan persetujuan pekerjaan. Agen pelaksana memperbaikinya atau menjelaskan mengapa suatu temuan keliru. Peninjau lanjutan memeriksa penyelesaian itu dan perubahan berikutnya. Review yang tidak dapat berjalan tidak dianggap lulus.

Implementasi hook review · Instruksi peninjau

Pemeriksaan otomatis dan restore sungguhan

Review independen didampingi pemeriksaan otomatis yang ketat. golangci-lint dan pemeriksa arsitektur kami memeriksa dependensi backend, batas modul, dan aturan migrasi. Pemeriksaan API memvalidasi kontrak OpenAPI dan kode hasil generasi. Frontend memeriksa TypeScript, React, impor antarlapisan, gaya, dan pelokalan.

Ruff dan ty memeriksa format, aturan kode, dan tipe Python. ShellCheck memeriksa skrip shell, sedangkan actionlint memeriksa workflow GitHub Actions. Hook sebelum commit memeriksa file backend, frontend, dan Python yang terkait tanpa menulis ulang file. CI juga menjalankan pemeriksaan lint.

Pemeriksaan lint backend · Pemeriksaan lint frontend · Pemeriksaan Python

Pengujian memeriksa perilaku nyata. Backend diuji melalui API aplikasi, sedangkan mesin database diperiksa dengan database sungguhan dalam container. Skenario menyeluruh membuat backup, melakukan restore, lalu memeriksa data hasil restore. Pengujian lain mencakup upgrade, layar frontend, dan alur browser dengan perbandingan visual.

Pemeriksaan dipilih sesuai perubahan. Rangkaian pengujian wajib untuk rilis berjalan pada amd64 dan arm64. Agen pelaksana menjalankan pemeriksaan lint dan pengujian terkait sebelum review. Peninjau memeriksa buktinya tanpa menjalankan ulang perintah tersebut.

Strategi pengujian dan perintah

Sebelum publikasi, CodeQL dan Semgrep menganalisis kode, Gitleaks mencari rahasia, dan dependensi diperiksa untuk menemukan kerentanan. Trivy memindai image container dan Dockerfile.

Pemeriksaan CI wajib harus lulus sebelum rilis. Keamanan dan keandalan.

Bagaimana cara membuat backup Databasus itu sendiri?

Untuk membuat backup instance Databasus (termasuk semua konfigurasi, database, dan kredensial), ikuti langkah berikut:

  1. Buka /opt/databasus (atau folder tempat Databasus diinstal)
  2. Masuk ke direktori databasus-data

Yang perlu di-backup:

  • secret.key: kunci enkripsi kredensial
  • /pgdata: database PostgreSQL internal Databasus yang berisi semua konfigurasi dan metadata backup

Jika memakai penyimpanan lokal untuk backup, kamu juga bisa membuat backup folder backups.

Penting: Ada dua skenario pemulihan yang berbeda:

  • Memulihkan backup tanpa antarmuka Databasus: Backup database bisa dipulihkan hanya dengan file secret.key, tanpa memerlukan Databasus atau data internalnya. Lihat panduan pemulihan manual untuk petunjuk lengkap.
  • Restore antarmuka Databasus dan seluruh konfigurasi: Untuk restore antarmuka Databasus beserta seluruh konfigurasi, backup terjadwal, dan riwayat backup, kamu perlu membuat backup secret.key sekaligus folder /pgdata (yang berisi metadata enkripsi dan seluruh konfigurasi Databasus).

Untuk restore Databasus di server lain: buat kembali struktur folder databasus-data dengan file hasil backup, lalu jalankan Databasus.

Bagaimana program open-source Anthropic dan OpenAI mendukung Databasus?

Pada Maret 2026, Databasus diterima dalam Claude for Open Source dari Anthropic dan Codex for Open Source dari OpenAI. Pengakuan dari dua perusahaan AI terkemuka dunia bahwa proyek ini merupakan perangkat lunak open-source penting bagi industri sangat berarti bagi kami, terutama mengingat persyaratan kelayakan kedua program yang tinggi.

Apa artinya bagi pengguna? Ini menjadi satu lagi penanda keandalan bahwa proyek telah dievaluasi secara independen dan diakui oleh para pemimpin industri sebagai infrastruktur penting yang layak didukung. Akses tanpa batas ke AI terbaru membantu kami meningkatkan kualitas kode, mempercepat review keamanan, dan terus mengembangkan proyek secara aktif.

Databasus diterima dalam program Claude for Open Source dari AnthropicDatabasus diterima dalam program Codex for Open Source dari OpenAI