Daftar Isi
- Tiga cara backup gagal
- Langkah 1: Buat kanal yang bisa menarik perhatian Anda
- Langkah 2: Tangkap kegagalan dengan skrip pembungkus
- borg dan borgmatic
- Langkah 3: Tangkap backup yang tidak pernah berjalan
- Langkah 4: Pastikan backup segar dan bisa direstore
- Langkah 5: Berdering hanya saat penting
- Pertanyaan yang sering diajukan
- Bagaimana cara mendapat notifikasi saat backup gagal?
- Kode keluar restic mana yang perlu di-alert?
- Bagaimana tahu backup berhenti berjalan secara diam-diam?
- Apakah kode keluar sukses cukup untuk mempercayai backup?
- Bisakah saya ditelepon, bukan dikirimi email?
- Penutup
- Artikel terkait
Kebanyakan orang baru sadar backup mereka rusak pada hari mereka membutuhkannya. Job-nya keluar dengan error tiga minggu lalu, tidak ada yang membaca lognya, dan snapshot terbaru ternyata lebih tua daripada kesalahan yang ingin Anda batalkan.
Solusinya bukan alat backup yang lebih bagus. Solusinya memastikan masalah backup sampai ke manusia dalam jam yang sama saat terjadi. Panduan ini menunjukkan caranya untuk restic dan borg (serta apa pun yang berjalan dari shell), mencakup tiga cara backup benar-benar gagal, lengkap dengan skrip yang bisa langsung Anda salin. Langkah terakhir mengirim alert ke ponsel Anda lewat Echobell, sehingga backup yang rusak berdering, bukan mengendap di kotak masuk email.
Tiga cara backup gagal
Memantau hanya yang pertama adalah kesalahan paling umum.
- Berjalan lalu gagal. Repositori terkunci, disk penuh, password salah, jaringan putus. Alat keluar dengan kode bukan nol.
- Berjalan tetapi setengah berhasil. restic keluar dengan kode
3ketika snapshot terbuat tetapi sebagian file tidak bisa dibaca. borg keluar dengan1untuk peringatan. Keduanya mudah diabaikan, dan keduanya bisa menyembunyikan masalah izin akses yang diam-diam melewatkan direktori terpenting Anda. - Tidak pernah berjalan. Server mati, timer dinonaktifkan, crontab tertimpa. Tidak ada error karena tidak ada proses. Inilah kegagalan yang paling mematikan.
Masing-masing butuh detektor yang berbeda, jadi kita akan membangun ketiganya.
Langkah 1: Buat kanal yang bisa menarik perhatian Anda
Di Echobell, buat kanal bernama backups dan setel tipe notifikasinya ke Panggilan untuk job yang penting. Salin URL webhook-nya:
https://hook.echobell.one/t/<channel-token>
Beri template yang masih masuk akal saat setengah tertidur, memakai field yang akan kita kirim di bawah:
Judul: Backup {{status}} di {{host}}
Isi: {{job}}: {{detail}}
Lihat referensi template untuk sintaksnya.
Langkah 2: Tangkap kegagalan dengan skrip pembungkus
Skrip pembungkus kecil mengubah kode keluar menjadi alert. Simpan sebagai /usr/local/bin/backup-run:
#!/usr/bin/env bash
set -uo pipefail
HOOK="https://hook.echobell.one/t/<channel-token>"
JOB="nightly-restic"
alert() {
curl -fsS -m 10 -X POST "$HOOK" \
-H "Content-Type: application/json" \
-d "{\"job\":\"$JOB\",\"host\":\"$(hostname)\",\"status\":\"$1\",\"detail\":\"$2\"}" || true
}
restic backup /srv /etc --exclude-caches
code=$?
case $code in
0) ;; # sukses: tetap diam
3) alert "incomplete" "Snapshot saved, but some files were unreadable" ;;
11) alert "locked" "Repository is locked by another process" ;;
12) alert "auth-failed" "Wrong repository password" ;;
*) alert "failed" "restic exited with code $code" ;;
esac
exit $code
Mengapa detailnya penting:
set -esengaja tidak dipakai, agar skrip tetap sampai ke alert setelah restic gagal.|| truepadacurlberarti webhook yang tidak terjangkau tidak akan menutupi kode keluar yang sebenarnya.-m 10mencegah panggilan jaringan yang menggantung memblokir jadwal berikutnya.
Kode keluar restic yang dipakai di atas terdokumentasi di manual restic: 0 sukses, 1 error fatal, 3 snapshot terbuat tetapi sebagian file sumber tidak terbaca, 10 repositori tidak ada, 11 gagal mengunci, 12 password salah. Cocokkan dengan restic version di mesin Anda sendiri, karena kode ditambahkan seiring waktu.
borg dan borgmatic
borg mengembalikan 0 untuk sukses, 1 untuk peringatan, dan 2 atau lebih untuk error. File yang berubah di tengah backup menghasilkan 1, hal yang lumrah untuk direktori log, jadi pendekatan umumnya adalah menelepon hanya untuk 2 ke atas dan mengirim notifikasi senyap untuk 1:
borg create --stats ::'{hostname}-{now}' /srv /etc
code=$?
if [ "$code" -ge 2 ]; then
alert "failed" "borg exited with code $code"
elif [ "$code" -eq 1 ]; then
alert "warning" "borg finished with warnings"
fi
Kalau Anda memakai borgmatic, hook on_error-nya menjalankan perintah ketika borgmatic sendiri mengalami error, dan di situlah tempat alami untuk curl yang sama. Perhatikan batasan yang diakui sendiri oleh dokumentasi borgmatic: jika borgmatic tidak pernah berjalan, on_error tidak pernah terpicu. Itu kegagalan nomor tiga, dan butuh Langkah 3.
Langkah 3: Tangkap backup yang tidak pernah berjalan
Pembungkus hanya bisa melaporkan proses yang benar-benar terjadi. Untuk menangkap keheningan, balik logikanya: backup mengirim ping ke monitor saat berhasil, dan monitor memberi tahu Anda saat ping terlambat. Ini disebut dead man's switch.
Healthchecks.io (hosted maupun self-hosted) melakukan persis ini:
- Buat check dengan jadwal
0 3 * * *dan grace time satu atau dua jam. - Tambahkan ping-nya di akhir job agar hanya terkirim saat sukses.
- Di integrasi check tersebut, tambahkan Webhook yang mengarah ke URL kanal Echobell Anda.
Ping diletakkan di akhir skrip pembungkus:
# di backup-run, tepat sebelum `exit $code` terakhir; ping hanya saat sukses
if [ $code -eq 0 ]; then
curl -fsS -m 10 --retry 3 -o /dev/null https://hc-ping.com/<your-uuid>
fi
Healthchecks juga mendukung varian ping /start dan /fail dan bisa menerima kode keluar di URL, sehingga satu check juga bisa menangkap job yang menggantung. Hasilnya: server mati, timer nonaktif, dan baris crontab yang terhapus semuanya berujung sama, ponsel yang berdering. Untuk pola umum dan monitor lainnya, lihat alert kegagalan cron job.
Langkah 4: Pastikan backup segar dan bisa direstore
Backup bisa berjalan sesuai jadwal, keluar dengan 0, dan tetap tidak berguna, misalnya ketika Anda mem-backup direktori kosong setelah mount gagal. Tambahkan dua pemeriksaan murah pada job harian terpisah:
Usia snapshot. Beri alert jika snapshot terbaru lebih tua dari yang Anda harapkan:
latest=$(restic snapshots --latest 1 --json | jq -r '.[0].time')
age_h=$(( ( $(date +%s) - $(date -d "$latest" +%s) ) / 3600 ))
if [ "$age_h" -gt 30 ]; then
alert "stale" "Newest snapshot is ${age_h}h old"
fi
Integritas repositori. restic check memverifikasi struktur repositori. Jalankan mingguan; untuk repositori besar, restic check --read-data-subset=5% mengambil sampel data tanpa membaca semuanya. Beri alert pada kode keluar bukan nol.
Keduanya tidak menggantikan uji restore yang sebenarnya. Setiap kuartal, restore satu file yang bisa Anda verifikasi ke direktori sementara. Itu satu-satunya uji yang membuktikan backup berfungsi.
Langkah 5: Berdering hanya saat penting
Kalau setiap peringatan menelepon Anda, Anda akan membisukan kanalnya, dan setelah itu ia tidak akan berdering untuk yang benar-benar penting. Gunakan kondisi Echobell untuk memisahkan tingkatan dalam satu kanal:
status == "failed" || status == "stale" || status == "auth-failed"
Kirim incomplete dan warning ke kanal kedua yang Sensitif Waktu atau normal, sehingga muncul di layar kunci tanpa dering. Tambahkan jendela waktu jika Anda ingin kegagalan di siang hari berjalan senyap, memakai variabel UTC yang dijelaskan di referensi kondisi.
Pertanyaan yang sering diajukan
Bagaimana cara mendapat notifikasi saat backup gagal?
Bungkus perintah backup, baca kode keluarnya, dan kirim webhook pada setiap kode bukan nol. Tambahkan dead man's switch seperti Healthchecks.io agar Anda juga tahu tentang proses yang tidak pernah dimulai.
Kode keluar restic mana yang perlu di-alert?
Beri alert keras untuk 1, 10, 11, dan 12, yang berarti kegagalan sungguhan. Perlakukan 3 (snapshot terbuat tetapi sebagian file tidak terbaca) sebagai peringatan yang perlu diselidiki, karena bisa menyembunyikan masalah izin akses.
Bagaimana tahu backup berhenti berjalan secara diam-diam?
Gunakan heartbeat: job mengirim ping ke monitor saat sukses, dan monitor memberi alert saat ping terlambat. Hook error tidak bisa menangkap ini karena tidak ada proses yang berjalan untuk memunculkan error.
Apakah kode keluar sukses cukup untuk mempercayai backup?
Tidak. Itu hanya berarti alatnya selesai, bukan bahwa datanya lengkap atau bisa direstore. Periksa usia snapshot, jalankan pemeriksaan integritas berkala, dan uji restore secara rutin.
Bisakah saya ditelepon, bukan dikirimi email?
Bisa. Email mudah terlewat. Kanal panggilan di Echobell berperilaku seperti telepon masuk dan menembus Mode Fokus iOS, sehingga backup gagal pukul 03.00 tetap terdengar.
Penutup
Tiga detektor menutup tiga mode kegagalan: pembungkus kode keluar untuk proses yang gagal, pemeriksaan kesegaran untuk proses yang berhasil tetapi tidak berguna, dan heartbeat untuk proses yang tidak pernah terjadi. Arahkan ke kanal panggilan, simpan peringatan ringan di kanal yang lebih sunyi, dan backup yang rusak menjadi perbaikan lima menit, bukan akhir pekan yang hilang.
Unduh Echobell untuk iPhone atau dapatkan di Google Play, buat kanal backups, lalu jalankan skrip pembungkus sekali dengan password yang sengaja dibuat salah untuk mendengar deringnya.