Çalışmayı bırakan bir yedekleme görevi bunu neredeyse hiç duyurmaz. cron postası kimsenin okumadığı bir kutuya gider, betik sıfırdan farklı bir kodla boşluğa çıkar ve başarısızlık, ona ihtiyaç duyulan o tek günde ortaya çıkar. Çözüm, başarısızlığı değil başarıyı izlemektir.

Ne olduğunu öğrenin

journalctl -u backup.service -n 100 --no-pager
tail -100 /var/log/backup.log
ls -la /srv/backup/ | tail          # has anything arrived recently

Dört alışılmış sebep

  • Yer yok — hedef dolmuştur. df -h. Saklama süresi budama yapmaz: bkz. Saklama süresi.
  • Kimlik bilgileri süresi doldu — döndürülmüş bir anahtar ya da bir S3 jetonu; kopya yerelde yazılır ve hiç yola çıkmaz.
  • Okunamayan bir dosya — izinler değişmiştir ve rsync ya da tar, işin çoğunu bitirmiş olmasına rağmen sıfırdan farklı bir kodla çıkar.
  • Veritabanı dökümü başarısız oldu — bir kilit zaman aşımı ya da eksik bir yetki; oysa işin dosya kısmı başarılıydı ve çalışma iyi görünüyordu.

Betiği yüksek sesle başarısız olacak biçimde yazın

#!/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

set -o pipefail olmadan, gzip başarılı olduğu her durumda mysqldump | gzip başarı bildirir — mysqldump yolun yarısında ölmüş olsa bile. Eksik olan bu tek seçenek, kesilmiş bir dökümün sağlam sanılıp saklanmasının en yaygın sebebidir.

Hatalara değil, sessizliğe uyarı kurun

Görev başarılı olduğunda bir ölü adam anahtarına sinyal göndersin. Sinyal gelmeyi kesince haberiniz olur; bu, sunucunun kapalı olduğu ve hiç hata üretilmediği durumu da kapsar.

# last line of the backup script
curl -fsS -m 10 --retry 3 https://hc-ping.com/your-uuid > /dev/null
Çıkış koduna baktığınız gibi BOYUTA da bakın. Birdenbire geçen haftakinin onda biri olan bir döküm, başarı bildirmiş bir başarısızlıktır — ve her sessiz yedekleme faciasının biçimi budur.