Tugas pencadangan yang berhenti bekerja hampir tak pernah mengumumkannya. Surat dari cron masuk ke kotak yang tak dibaca siapa pun, skripnya keluar dengan kode bukan nol ke ruang hampa, dan kegagalannya ditemukan pada satu-satunya hari ia dibutuhkan. Perbaikannya adalah menjadikan keberhasilan sebagai hal yang dipantau, bukan kegagalan.
Cari tahu apa yang terjadi
journalctl -u backup.service -n 100 --no-pager
tail -100 /var/log/backup.log
ls -la /srv/backup/ | tail # has anything arrived recently
Empat sebab yang lazim
- Kehabisan ruang — tujuannya penuh.
df -h. Masa simpan tidak melakukan pemangkasan: lihat Masa simpan. - Kredensial kedaluwarsa — kunci yang diputar atau token S3, sehingga salinannya ditulis di lokal dan tak pernah berangkat.
- Berkas yang tak bisa dibaca — izinnya berubah, lalu rsync atau tar keluar dengan kode bukan nol padahal sebagian besar pekerjaannya sudah selesai.
- Dump basis datanya gagal — tenggat kunci atau hak akses yang hilang, sementara bagian berkasnya berhasil dan jalannya tampak baik-baik saja.
Buat skripnya gagal dengan berisik
#!/usr/bin/env bash
set -euo pipefail # stop at the first error, and at an unset variable
trap 'echo "BACKUP FAILED at line $LINENO" | mail -s "backup failed" ops@example.com' ERR
Tanpa set -o pipefail, mysqldump | gzip melaporkan keberhasilan setiap kali gzip berhasil — bahkan ketika mysqldump mati di tengah jalan. Satu pilihan yang hilang itu adalah sebab paling umum sebuah dump terpotong tersimpan sebagai dump yang baik.
Berilah peringatan atas kesunyian, bukan atas galat
Buatlah tugas itu mengirim denyut ke sebuah sakelar orang mati setiap kali berhasil. Kalau denyutnya berhenti datang, Anda diberi tahu — dan itu juga mencakup keadaan ketika servernya mati dan tak ada galat apa pun yang dihasilkan.
# last line of the backup script
curl -fsS -m 10 --retry 3 https://hc-ping.com/your-uuid > /dev/null