Belajar Bacula - Performance & Monitoring

#Pendahuluan

Sistem backup yang "berjalan" adalah hal yang berbeda dengan sistem backup yang "terjaga". Yang berjalan menghasilkan job sukses; yang terjaga juga memberitahu kalian saat tidak. Di episode 20 kita menyatukan dua kemampuan: membuat backup berjalan lebih cepat dengan tuning, dan memastikan setiap kegagalan terlihat — bukan menunggu ditemukan.

Mulai dari tuning performa yang berbasis pengukuran, lalu monitoring dengan bconsole, plugin Nagios/Zabbix, dan alert kegagalan job.

#Tuning Performa

#Concurrent Jobs

Bacula bisa menjalankan beberapa job bersamaan. Parameter Maximum Concurrent Jobs ada di beberapa resource:

Director {
  Name = bacula-dir
  Maximum Concurrent Jobs = 20
}

Device {
  Name = FileStorage
  Maximum Concurrent Jobs = 4
  ...
}

Semakin banyak job bersamaan, semakin besar beban CPU, disk, dan catalog. Aturan praktis: ukur dulu, naikkan bertahap. Mulai dengan 2-4 job per device lalu naikkan sambil memantau.

#Spool Size

Spooling membuat Storage Daemon menulis data ke spool file (disk cepat) sebelum memindahkannya ke media final. Ini meminimalkan jeda pada media sekuensial (tape) dan menghindari tape "shoe-shining" (bolak-balik maju mundur). Konfigurasinya di bacula-sd.conf:

Storage {
  Name = bacula-sd
  Spool Directory = /var/lib/bacula/spool
  Maximum Spool Size = 5 GB
  Maximum Job Spool Size = 1 GB
}

Spool yang terlalu kecil tidak membantu; yang terlalu besar bisa penuh di saat tidak terduga. Ukuran spool = ukuran rata-rata satu job × toleransi.

#Device Polling

Storage Daemon memeriksa media secara berkala (Device Polling Interval). Untuk tape yang sedang menunggu operator, polling menentukan seberapa cepat Bacula sadar tape terpasang:

Device {
  Name = TapeDrive
  Device Polling Interval = 15 min
  ...
}

Interval yang terlalu sering membebani SD; terlalu jarang memperlambat deteksi media baru.

#Benchmark

Semua tuning harus berdasar data. Buat benchmark sederhana:

* run job="Backup Web" level=Full yes
* list jobs | grep "Backup Web"

Catat kolom Bytes dan Job Elapsed Time. Bagi bytes dengan waktu untuk mendapatkan throughput per job. Bandingkan setelah setiap perubahan konfigurasi — inilah kompas tuning kalian.

#Monitoring

#bconsole status

Monitoring pertama selalu bconsole:

* status dir
* status sd
* status all

Biasakan juga memeriksa job yang gagal:

* list jobs | grep -E "Error|Canceled" | tail -10

#Skrip Alert Sederhana

Sebelum bergantung pada tool besar, buat skrip notifikasi non-interaktif — bconsole mendukung perintah sekali jalan:

#!/bin/bash
FAILED=$(bconsole -c /etc/bacula/bconsole.conf -c 'list jobs' \
  | grep -cE "Error|Canceled")
if [ "$FAILED" -gt 0 ]; then
  echo "Job Bacula bermasalah" | mail -s "[BACULA] Job gagal" oncall@example.com
fi

Jalankan via cron setiap 15 menit. Ini jaring pengaman minimum yang menyelamatkan banyak admin sebelum monitoring penuh terpasang.

#Plugin Nagios/Zabbix

Untuk integrasi penuh, pakai plugin yang memakai output bconsole:

• Nagios: plugin memanggil bconsole -c 'list jobs' dan mengembalikan OK/CRITICAL berdasarkan status. Skrip check_bacula tersedia di repositori komunitas.
• Zabbix: item berjalan di system.run menjalankan perintah bconsole non-interaktif, atau memakai trapper yang menerima hasil job dari skrip di server Bacula.

/usr/lib/nagios/plugins/check_bacula -w 1 -c 3
# OK: job terakhir sukses 5 menit lalu
# CRITICAL: tidak ada job sukses dalam 3 hari

Buatlah kriteria alert berbasis usia job sukses terakhir per client — bukan sekadar status job terakhir, karena sistem yang tidak menjalankan apa-apa juga "tidak gagal".

#Alert on Job Failure

Sumber alert yang paling langsung adalah resource Messages di tiap daemon. Mail failure secara spesifik:

Messages {
  Name = Standard
  mail = oncall@example.com = JobErrors, FatalErrors
}

Dengan JobErrors, FatalErrors, email hanya dikirim saat job benar-benar bermasalah — bukan spam per sukses. Untuk environment tim, tambahkan integrasi ke chat/ops tool (webhook) lewat script yang dipanggil mailcommand.

#Membangun Ritual Monitoring

Monitoring bukan satu tool — ia ritual harian:

1. Pagi: list jobs | grep Error — lihat semalam.
2. Per 15 menit: skrip alert kegagalan.
3. Per jam: status sd untuk device yang macet.
4. Bulanan: benchmark ulang throughput dan tinjau job yang sering gagal.

* list jobs | tail -30

#Penutup

Inti yang harus dibawa pulang:

• Concurrent jobs dan spool tuning berdasar pengukuran, bukan tebakan.
• Device Polling Interval menentukan responsivitas deteksi media.
• Benchmark throughput (bytes ÷ waktu) adalah kompas perubahan konfigurasi.
• Monitoring: bconsole status + skrip alert + plugin Nagios/Zabbix.
• Alert berbasis usia job sukses terakhir dan berisi konteks job.

Di episode 21 selanjutnya kita akan menjelajahi roadmap dan komunitas Bacula — evolusi Enterprise (plugin, dedup), maintenance Community, konferensi Bacula, serta sumber daya bacula.org, mailing list bacula-users, dan GitHub bacula/bacula. Inilah cara kalian tetap mengikuti arah proyek yang sudah berjalan 25 tahun.