Verifikasi restore

Backup yang selesai tanpa error belum tentu bisa di-restore. Satu-satunya bukti nyata adalah mencoba restore. Databasus melakukannya secara terjadwal:

• mengambil backup terbaru
• menjalankan restore ke container database sementara
• memeriksa kewajaran hasil restore dengan membandingkannya terhadap database sumber
• menghapus container
• melaporkan hasilnya

Apa itu agen verifikasi?

Agen verifikasi adalah binary Go kecil yang dijalankan pada mesin yang kamu kendalikan. Mesin apa pun dengan CPU, RAM, dan ruang disk tersisa bisa digunakan. Agen mendaftar ke Databasus, mengambil tugas verifikasi dari antrean, menjalankannya secara lokal, lalu mengirimkan hasilnya kembali.

Yang perlu disiapkan

• Host dengan akses HTTPS keluar ke URL Databasus milikmu.
• Docker tersedia pada host tersebut. Agen membuat container database sementara dengan versi mayor yang sesuai untuk setiap tugas.
• Kapasitas disk untuk setiap tugas verifikasi yang mencakup ukuran file backup, ukuran mentah database, dan ruang cadangan tambahan.
• Setidaknya 1 core CPU dan RAM 512 MB tersedia untuk setiap tugas yang berjalan bersamaan.

Mengapa checksum saja tidak cukup?

Checksum dan exit code bisa mendeteksi beberapa jenis kegagalan, tetapi sama sekali tidak mendeteksi yang lain:

• Checksum mendeteksi kerusakan bit pada file arsip, tetapi tidak menunjukkan apakah dump itu sendiri lengkap atau valid secara semantik.
• Exit code dump menunjukkan bahwa perintah dump berjalan. Ini tidak mendeteksi role yang tidak memiliki izin baca atas objek tertentu, extension yang hilang di sumber, atau ketidakcocokan tablespace. Semua itu bisa menyebabkan objek dilewati atau dibuang tanpa pemberitahuan.
• Verifikasi restore benar-benar memproses arsip menggunakan tool restore bawaan database dan menghitung baris per tabel. Inilah satu-satunya pemeriksaan yang mendeteksi semua masalah di atas. Jika backup tidak bisa di-restore, kamu mengetahuinya sebelum membutuhkannya, bukan saat bencana terjadi.

Konfigurasi

Buat agen di antarmuka

Buka Settings → Verification agents, lalu klik Create verification agent. Pilih nama yang jelas seperti staging-verifier atau eu-west-host-1. Dialog berikutnya menampilkan token dan ID agen.

Token ditampilkan hanya satu kali. Salin sebelum menutup dialog. Jika hilang, gunakan tindakan Rotate token pada baris agen untuk menerbitkan token baru. Token lama berhenti berfungsi pada heartbeat agen berikutnya. Dialog selanjutnya menampilkan perintah instalasi sesuai arsitektur server, sama dengan perintah yang dijelaskan di bawah.

Jalankan agen di server

Masuk melalui SSH ke mesin yang akan menjalankan verifikasi. Unduh binary agen terlebih dahulu. Ganti https://your-databasus-host dengan URL Databasus milikmu, dan ganti amd64 dengan arm64 jika server menggunakan ARM:

curl -L -o verification-agent "https://your-databasus-host/api/v1/system/verification-agent?arch=amd64" \
  && chmod +x verification-agent

Lalu jalankan agen. ID dan token agen berasal dari dialog pada langkah sebelumnya:

./verification-agent start \
  --databasus-host=https://your-databasus-host \
  --agent-id=<AGENT_ID> \
  --token=<TOKEN> \
  --max-cpu=2 \
  --max-ram-mb=2048 \
  --max-disk-gb=20 \
  --max-concurrent-jobs=1

start menjalankan agen sebagai daemon dan menyimpan flag ke databasus-verification.json di direktori kerja. Saat dijalankan ulang, cukup gunakan ./verification-agent start tanpa flag. Log ditulis ke databasus-verification.log di samping binary.

Keempat flag --max-* menetapkan anggaran, bukan alokasi per tugas. Agen melaporkannya ke Databasus pada setiap heartbeat, lalu Databasus membaginya ke seluruh tugas bersamaan yang diizinkan. Dengan --max-cpu=2 --max-ram-mb=2048 --max-concurrent-jobs=1, satu tugas mendapat seluruh 2 CPU dan RAM 2 GB. Dengan --max-concurrent-jobs=2, setiap tugas mendapat 1 CPU dan 1 GB. Batas minimumnya adalah 1 CPU dan 512 MB per tugas. Jika anggaran tidak mencukupi, agen melaporkan kapasitas tugas bersamaan yang lebih rendah. Anggaran disk paling mudah keliru: setiap tugas memerlukan ruang untuk ukuran file backup, ukuran mentah database, serta ruang cadangan hingga 5 GB. Jadi, atur --max-disk-gb cukup jauh di atas total kebutuhan itu untuk database terbesar.

Mengelola agen

Binary yang sama menyediakan empat subcommand:

• ./verification-agent status menampilkan apakah daemon berjalan dan tugas apa yang sedang dikerjakan.
• ./verification-agent stop menghentikan daemon. Verifikasi yang sedang berjalan dilaporkan ke Databasus sebagai gagal dan dimasukkan kembali ke antrean.
• ./verification-agent start menjalankan ulang daemon. Flag disimpan sejak pertama kali dijalankan. Sertakan --token=<NEW> setelah rotasi untuk memperbarui token tersimpan.
• ./verification-agent run berjalan di foreground, bukan sebagai daemon. Gunakan saat menjalankan agen dalam unit systemd atau container Docker karena supervisor tersebut mengharapkan proses tidak melakukan fork ke background.

Halaman Settings menampilkan tiga tindakan berikon pada setiap baris agen: melihat kembali perintah instalasi tanpa menampilkan token, merotasi token, dan menghapus agen. Penghapusan aman. Verifikasi yang sedang ditugaskan ke agen itu dikembalikan ke antrean dan diambil oleh agen lain jika tersedia.

Jadwal dan notifikasi

Verifikasi restore diatur per database. Buka pengaturan verifikasi database, aktifkan Scheduled verification, lalu pilih interval.

Pilihan interval

• After backup memberikan jaminan terkuat: setiap backup yang berhasil langsung diverifikasi begitu proses backup selesai.
• Hourly, daily, weekly, monthly memilih frekuensi dan waktu pelaksanaan.
• Cron menggunakan ekspresi cron UTC untuk jadwal di luar preset. Contoh: 0 4 * * 0 (setiap Minggu pukul 4:00 AM UTC) dan 0 */6 * * * (setiap enam jam).

Cara antrean menangani "After backup"

Verifikasi biasanya lebih lambat daripada backup yang diperiksanya. Jika backup baru masuk lebih cepat daripada verifikasi selesai, antrean akan terus bertambah. Databasus mencegahnya dengan membatalkan verifikasi yang masih menunggu untuk database yang sama setiap kali backup baru masuk. Hanya backup terbaru yang menunggu di antrean. Ini pilihan yang disengaja: lebih baik melewati verifikasi backup lama daripada menghabiskan berjam-jam memeriksa backup yang tidak akan dipakai untuk restore.

Menjalankan secara manual

Kamu juga bisa menjalankan verifikasi satu kali dari tab Restore verifications pada database tanpa mengubah jadwal. Ini berguna untuk memeriksa backup tertentu atau menguji agen baru secara end-to-end sebelum mengandalkannya untuk beban terjadwal.

Notifikasi

Hasil berhasil dan gagal bisa dikirim melalui kanal notifikasi apa pun yang sudah dikonfigurasi untuk database. Kedua checkbox, Verification success dan Verification failed, berdiri sendiri. Sebagian besar tim hanya mengaktifkan notifikasi kegagalan agar tidak kewalahan menerima notifikasi. Lihat dokumentasi kanal notifikasi untuk menghubungkan Slack, Microsoft Teams, Discord, email, dan lainnya.

Membaca hasil

Setiap percobaan verifikasi muncul sebagai satu baris pada tab Restore verifications di database. Statusnya berupa Pending, Running, Successful, Failed, atau Canceled. Klik baris untuk membuka panel berisi linimasa lengkap, exit code restore, ukuran database hasil restore, jumlah schema dan tabel, serta rincian jumlah baris tiap tabel. Untuk verifikasi gagal, pesan kegagalan ditampilkan di bagian atas panel.