Belajar Rsync - Monitoring & Logging

#Pendahuluan

Backup yang berjalan tanpa terpantau adalah ilusi keamanan. Kalian baru tahu backup rusak ketika butuh restore — dan saat itu sudah terlambat. Episode 20 menutup celah ini: bagaimana membuat backup rsync terukur, tercatat, dan ter-alert sehingga kegagalan terdeteksi dalam hitungan menit, bukan bulan. Kita bedah lima lapisan: log, exit codes, notifikasi, integrasi alerting, dan audit berkala — semuanya bisa dibangun dengan alat yang sudah ada di server kalian.

#Log Rsync

Log yang baik punya tiga sifat: bermarka waktu, menyimpan konteks, dan menyimpan ringkasan. Skrip di episode 10 sudah menulis marka; tingkatkan dengan ringkasan statistik:

Skrip backup dengan log ringkas

#!/bin/bash
LOG=/var/log/rsync.log
{
  echo "=== $(date '+%F %T') rsync mulai ==="
  rsync -avh --stats --delete /home/data/ /backup/daily/
  echo "=== exit=$? selesai $(date '+%F %T') ==="
} >> "$LOG" 2>&1

Format satu blok per run (=== mulai === … === selesai ===) memudahkan parsing. Untuk log yang mudah dianalisis, pertimbangkan format satu baris per run — ideal untuk query dan chart, dan kita manfaatkan di bagian Prometheus di bawah:

Log satu baris per run

echo "$(date '+%F %T') rc=$RC sent=$SENT recv=$RECV speedup=$SPEEDUP" >> "$LOG"

#Exit Codes

Sudah dipetakan di episode 10: 0 sukses, 23 partial transfer, 24 file vanished, 255 error koneksi. Kunci penggunaannya di script:

Klasifikasi exit code

RC=$?
if [ $RC -eq 0 ]; then
  STATUS="OK"
elif [ $RC -eq 23 ] || [ $RC -eq 24 ]; then
  STATUS="PARTIAL"   # ada file gagal/vanish — harus diperiksa
else
  STATUS="FAILED"
fi

Perlakukan 23/24 sebagai warning yang harus dilihat, bukan sukses: sebagian data mungkin tidak tersinkron. STATUS ini yang akan kalian kirim ke notifikasi dan alerting.

#Email on Failure

Notifikasi paling sederhana — email saat bukan 0 (pola episode 10):

Email saat gagal

if [ "$STATUS" != "OK" ]; then
  tail -30 "$LOG" | mail -s "Rsync $STATUS (rc=$RC) - $(hostname)" admin@example.com
fi

Untuk tim modern, ganti mail dengan webhook — Slack/Telegram/Mattermost cukup dengan curl:

Webhook Telegram saat gagal

curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
  -d chat_id="$CHAT_ID" -d text="Rsync $STATUS rc=$RC di $(hostname)"

Note

Terlalu banyak notifikasi = notifikasi mati rasa. Alert hanya untuk non-OK — pilih saluran yang benar-benar kalian lihat, karena email yang tidak pernah dibaca sama buruknya dengan tidak ada notifikasi. Run yang sukses cukup dicatat di log.

#Cron Wrapper + Alerting

Bentuk paling fleksibel: cron wrapper yang menjalankan backup, menulis status, dan mengeksposnya ke sistem monitoring. Pola Prometheus textfile collector (via node_exporter):

Tulis metrik Prometheus

#!/bin/bash
LOG=/var/log/rsync.log
rsync -avh --delete /home/data/ /backup/daily/ >> "$LOG" 2>&1
RC=$?
printf 'rsync_backup_last_status %s\n' "$RC" > /var/lib/node_exporter/rsync.prom
printf 'rsync_backup_last_run %s\n' "$(date +%s)" >> /var/lib/node_exporter/rsync.prom

node_exporter mem-publish file .prom sebagai metrik; Prometheus meng-scrape-nya setiap interval; Alertmanager mengirim alert saat rsync_backup_last_status ≠ 0 selama lebih dari N menit. Diagram alurnya:

Alur alerting

cron → skrip rsync → exit code → textfile .prom → node_exporter
   → Prometheus (rule) → Alertmanager → email/Slack/PagerDuty

Untuk Zabbix, polanya sama dengan cara yang berbeda: zabbix_sender mengirim status langsung ke server, atau item eksternal membaca log. Yang terpenting adalah prinsipnya, bukan toolnya: exit code backup harus menjadi metrik yang di-scrape.

#rsyslog untuk Daemon Mode

Saat memakai rsyncd (mode daemon), ia bisa menulis log ke syslog — dikelola oleh rsyslog — bukan hanya ke file sendiri. Konfigurasi /etc/rsyncd.conf:

/etc/rsyncd.conf

use syslog = yes
log format = %h %o %f %b

Setiap koneksi daemon kini masuk ke syslog dengan format host, operasi, file, dan byte. Di sisi rsyslog, arahkan facility tertentu ke file atau forward ke server log pusat:

/etc/rsyslog.d/rsync.conf

daemon.*  /var/log/rsyncd.log

Pengiriman ke log server pusat (misal @logserver:514) membuat audit daemon terpusat — berguna untuk memantau siapa yang menarik dari module, dan untuk investigasi jika ada akses mencurigakan.

#Review Backup Logs Berkala

Alat terbaik sekalipun tidak berarti tanpa manusia yang meninjaunya. Bangun kebiasaan audit:

Ringkasan status 30 hari terakhir

grep 'rc=' /var/log/rsync.log | awk '{print $1, $2, $5}'

Review berkala (mingguan/bulanan) dengan pertanyaan:

Adakah run non-0 yang luput dari alert?
Adakah pola PARTIAL berulang (file yang selalu gagal — tanda masalah permanen)?
Apakah ukuran transfer normal, atau ada lonjakan (indikasi data tambahan tak terduga)?
Apakah rotasi snapshot berjalan dan ruang disk terkendali?

Tip

Jadikan review backup sebagai agenda rutin (mingguan) dan masukkan "restore drill" berkala: coba pulihkan satu file acak dari snapshot seminggu lalu. Backup hanya terbukti bekerja saat restore-nya terbukti berhasil.

#Penutup

Pada episode 20 ini, kalian telah menjadikan backup rsync terukur dan terpantau.

Inti yang harus dibawa pulang:

Log dengan marka waktu dan satu baris ringkasan per run — mudah di-query.
Klasifikasi exit code: 0 OK, 23/24 partial (waspada), lainnya failed.
Notifikasi (email/webhook) hanya saat non-OK; alert yang kebanyakan = alert yang mati.
Cron wrapper mengekspor exit code ke metrik (Prometheus textfile / Zabbix).
rsyncd bisa log ke rsyslog; audit review dan restore drill berkala wajib.

Di episode 21 selanjutnya, kita lihat ke depan: roadmap & community — fokus keamanan berkelanjutan, maintenance rilis 3.4.x, tidak ada fitur besar yang direncanakan, pengelolaan lewat lists.samba.org, GitHub repo, dan mailing list rsync. Sampai jumpa di episode 21!