Belajar Borg Backup - Monitoring & Alerting

#Pendahuluan

Di episode 19 kita mengekspor metrik. Tapi metrik tanpa alert hanyalah grafik yang cantik — saat backup gagal di tengah malam, kalian ingin tahu, bukan sekadar melihat angka besok pagi. Episode 20 menutup lingkaran: memonitor borgmatic secara aktif, memicu alert pada dua kondisi paling penting (gagal dan terlambat), dan mengirimkannya ke kanal yang kalian benar-benar baca.

#Monitoring Log dan Metrik borgmatic

#Apa yang Dipantau

Dua sinyal paling berharga dari backup:

Status eksekusi: apakah backup terakhir sukses?
Staleness: kapan terakhir kali backup sukses? (Backup yang tidak pernah jalan itu sama bahayanya dengan backup yang gagal.)

Keduanya bisa diambil dari log borgmatic (--verbosity 1) atau dari metrik yang kita ekspor di episode 19. Untuk Prometheus, tambahkan metrik timestamp:

Metrik staleness

# HELP borg_backup_last_success_seconds Waktu backup sukses terakhir (unix)
# TYPE borg_backup_last_success_seconds gauge
borg_backup_last_success_seconds 1785300000

Alert "backup terlambat" hanyalah aturan: time() - borg_backup_last_success_seconds > 36h.

#Alert Saat Backup Gagal

#Hook on_error

Cara paling langsung: hook on_error borgmatic dijalankan persis saat backup gagal.

/etc/borgmatic/config.yaml

hooks:
  before_backup:
    - echo "Backup dimulai $(date)"
  after_backup:
    - echo "Backup selesai $(date)"
  on_error:
    - curl -fsS -X POST "https://ntfy.sh/backup-alerts" \
        -d "Backup GAGAL di $(hostname)"

ntfy adalah push notification gratis berbasis pub/sub — tanpa akun untuk penggunaan sederhana. Ganti dengan mail, curl ke Slack webhook, atau apa pun yang dimengerti tim kalian.

#Notifikasi Email/Slack/Telegram

Email cukup satu baris hook: echo "Backup gagal di $(hostname)" | mail -s "[BACKUP] Gagal" backup@example.com. Slack lewat webhook Incoming:

Alert Slack

hooks:
  on_error:
    - curl -fsS -X POST -H 'Content-type: application/json' \
        --data '{"text":"Backup gagal di '"$(hostname)"'"}' \
        https://hooks.slack.com/services/T000/B000/XXXX

Telegram — bot API:

Alert Telegram

hooks:
  on_error:
    - curl -fsS "https://api.telegram.org/bot<TOKEN>/sendMessage" \
        -d chat_id=<CHAT_ID> -d "text=Backup gagal di $(hostname)"

Warning

Jangan hardcode token Slack/Telegram di config.yaml yang masuk git. Ambil dari environment (${TELEGRAM_TOKEN} didukung borgmatic) atau dari file yang dibaca hook. Kredensial yang bocor di repo = alarm yang bisa dimanipulasi penyerang.

#Alert Saat Backup Terlambat

#Masalah dengan Alert Gagal Saja

on_error hanya memicu saat proses gagal. Kalau host mati total, cron tidak jalan, atau jaringan putus — tidak ada yang men-trigger on_error, dan tidak ada yang tahu. Backup yang terlambat butuh mekanisme pengawas eksternal.

#Healthchecks

Layanan seperti Healthchecks.io memecahkan masalah ini: borgmatic mengirim ping setiap backup selesai; jika ping tidak tiba dalam jadwal (misal 36 jam), Healthchecks mengirim alert. Ini deteksi "tidak ada yang terjadi" — bukan hanya "terjadi kesalahan".

Integrasi Healthchecks borgmatic

monitoring:
  healthchecks:
    ping_url: https://hc-ping.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Dengan baris ini saja, borgmatic otomatis ping sukses setelah backup selesai dan ping gagal saat error. Alert keterlambatan dikonfigurasi di dashboard Healthchecks (misal "alert jika tidak ada ping dalam 36 jam").

Borgmatic juga punya integrasi siap pakai lain: cronitor, pagerduty, pushover, ntfy, dan apprise.

#Alternatif Self-hosted

Untuk menghindari layanan pihak ketiga, implementasi sendiri sederhana:

Script exporter kita di episode 19 menulis borg_backup_last_success_seconds.
Prometheus Alertmanager (atau Zabbix/Nagios) mengevaluasi aturan staleness.
Alert diteruskan ke kanal tim.

#Menyusun Alerting yang Sehat

Matriks alerting

+--------------------+--------------------+----------------------+
| Kondisi            | Sinyal             | Kanal                |
+--------------------+--------------------+----------------------+
| Backup gagal       | on_error hook      | Slack/Telegram/Email |
| Backup terlambat   | Healthchecks miss  | Slack/Telegram/Email |
| Check gagal        | borg check exit    | Slack/Telegram/Email |
| Disk penuh         | node_exporter      | Prometheus alert     |
| Login SSH mencurigakan | auth.log      | SIEM/fail2ban        |
+--------------------+--------------------+----------------------+

Prinsip kuncinya: alert harus bisa ditindaklanjuti. Terlalu banyak alert = noise yang diabaikan; terlalu sedikit = blind spot. Mulai dari dua alert inti (gagal + terlambat), lalu perluas berdasarkan insiden nyata.

#Pitfall Umum

Hanya mengandalkan on_error: mati total tidak memicu on_error. Wajib ada pengawas eksternal (staleness/Healthchecks).
Token di config yang masuk git: enkripsi/isolasi kredensial.
Alert tanpa runbook: notifikasi "Backup GAGAL" tanpa langkah penanganan hanyalah stress. Tulis runbook singkat (cek log, cek disk, jalankan manual).
Testing sekali lalu lupa: uji alur alert berkala — sengaja gagalkan backup di staging dan pastikan notifikasi tiba.

#Penutup

Pantau dua sinyal: status eksekusi dan staleness (kapan terakhir sukses).
on_error hook memicu alert saat backup gagal.
Email/Slack/Telegram via hooks; hindari hardcode token.
Healthchecks (atau pengawas staleness) menangkap backup yang diam-diam tidak berjalan.
Alerting yang sehat: sedikit, bisa ditindaklanjuti, dan teruji berkala.

Di episode 21 kita menengok ke depan: roadmap & community — apa yang sedang dikerjakan proyek (Borg 2.0 stabil yang dinanti, fokus keamanan & performa), dan di mana kalian bisa berkontribusi dan bertanya: GitHub, dokumentasi, IRC/Matrix, dan Bountysource.