---
title: "Yedekleme hatası uyarıları: geri yüklemeden önce öğrenin"
description: "Yedekler haftalarca sessizce bozulur. restic ve borg hatalarını, eski snapshot'ları ve atlanan çalışmaları yakalayın; yedek bozulunca telefonunuz çalsın."
date: 2026-10-09
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - yedekleme izleme
  - restic
  - borg
  - hata uyarıları
  - telefon uyarıları
  - webhook
---

# Yedekleme hatası uyarıları: geri yüklemeden önce öğrenin

Çoğu insan yedeklerinin bozuk olduğunu tam da onlara ihtiyaç duyduğu gün fark eder. İş üç hafta önce hatayla bitmiş, kimse günlüğü okumamış ve en yeni snapshot, geri almaya çalıştığınız hatadan bile eski.

Çözüm daha iyi bir yedekleme aracı değil. Çözüm, yedekleme sorununun olduğu saat içinde bir insana ulaşmasını sağlamak. Bu rehber, restic ve borg için (ve kabuktan çalışan her şey için) bunu nasıl yapacağınızı gösteriyor: yedeklerin gerçekte başarısız olduğu üç yolu, kopyalayabileceğiniz betiklerle ele alıyor. Son adım uyarıyı [Echobell](/tr) ile telefonunuza gönderir; böylece bozuk bir yedek, posta kutusunda beklemek yerine telefonunuzu çaldırır.

## Yedeğin başarısız olduğu üç yol

Yalnızca birincisini izlemek en yaygın hatadır.

1. **Çalışır ve başarısız olur.** Depo kilitli, disk dolu, parola yanlış, ağ koptu. Araç sıfırdan farklı bir kodla çıkar.
2. **Çalışır ve yarım başarılı olur.** restic, snapshot oluşturulduğunda ama bazı dosyalar okunamadığında `3` koduyla çıkar. borg uyarılar için `1` ile çıkar. İkisi de kolayca göz ardı edilir ve ikisi de en önemli dizininizi sessizce atlayan bir izin sorununu gizleyebilir.
3. **Hiç çalışmaz.** Sunucu kapalıydı, zamanlayıcı devre dışı kalmış, crontab ezilmiş. Süreç olmadığı için hata da yoktur. İnsanları en çok yakan başarısızlık budur.

Her biri ayrı bir dedektör gerektirir; üçünü de kuracağız.

## Adım 1: Dikkatinizi çekebilecek bir kanal oluşturun

Echobell'de `backups` adlı bir kanal oluşturun ve önemli işler için bildirim türünü **Arama** yapın. Webhook URL'sini kopyalayın:

```
https://hook.echobell.one/t/<channel-token>
```

Yarı uykuda bile anlaşılır şablonlar verin; aşağıda göndereceğimiz alanları kullanıyoruz:

```
Başlık: Backup {{status}} on {{host}}
Gövde: {{job}}: {{detail}}
```

Sözdizimi için [şablon referansına](/tr/docs/template) bakın.

## Adım 2: Başarısızlıkları bir sarmalayıcı betikle yakalayın

Küçük bir sarmalayıcı, çıkış kodlarını uyarılara dönüştürür. Bunu `/usr/local/bin/backup-run` olarak kaydedin:

```bash
#!/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)  ;;                                   # başarı: sessiz kal
  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
```

Ayrıntıların neden önemli olduğu:

- `set -e` bilerek **kullanılmıyor**; böylece restic başarısız olsa bile betik uyarıya ulaşır.
- `curl` üzerindeki `|| true`, ulaşılamayan bir webhook'un gerçek çıkış kodunu gölgelemesini önler.
- `-m 10`, takılan bir ağ çağrısının sonraki zamanlanmış çalışmayı engellemesini önler.

Yukarıda kullanılan restic çıkış kodları restic kılavuzunda belgelenmiştir: `0` başarı, `1` ölümcül hata, `3` snapshot oluşturuldu ama bazı kaynak dosyalar okunamadı, `10` depo yok, `11` kilitlenemedi, `12` yanlış parola. Kodlar zamanla eklendiği için bunları kendi makinenizdeki `restic version` ile doğrulayın.

### borg ve borgmatic

borg başarı için `0`, uyarılar için `1`, hatalar için `2` ve üzerini döndürür. Yedekleme sırasında bir dosyanın değişmesi `1` üretir; günlük dizinlerinde bu olağandır. Bu yüzden yaygın yaklaşım yalnızca `2` ve üzerinde arama yapıp `1` için sessiz bir bildirim göndermektir:

```bash
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
```

borgmatic kullanıyorsanız `on_error` kancası, borgmatic'in kendisi hata aldığında bir komut çalıştırır; aynı `curl` için doğal yer burasıdır. borgmatic belgelerinin kendisinin belirttiği sınıra dikkat edin: borgmatic hiç çalışmazsa `on_error` asla tetiklenmez. Bu üçüncü başarısızlıktır ve 3. adımı gerektirir.

## Adım 3: Hiç çalışmayan yedeği yakalayın

Bir sarmalayıcı yalnızca gerçekleşen bir çalışmayı raporlayabilir. Sessizliği yakalamak için mantığı tersine çevirin: yedek **başarılı** olduğunda bir izleyiciye ping atar, ping **geciktiğinde** izleyici sizi uyarır. Buna dead man's switch denir.

[Healthchecks.io](https://healthchecks.io) (barındırılan ya da kendi sunucunuzda) tam olarak bunu yapar:

1. `0 3 * * *` zamanlamasıyla ve bir iki saatlik tolerans süresiyle bir check oluşturun.
2. Ping'ini işin sonuna ekleyin ki yalnızca başarıda tetiklensin.
3. Check'in entegrasyonlarında Echobell kanal URL'nizi gösteren bir **Webhook** ekleyin.

Ping, sarmalayıcının sonuna gider:

```bash
# backup-run içinde, son `exit $code` satırından hemen önce; yalnızca başarıda ping atar
if [ $code -eq 0 ]; then
  curl -fsS -m 10 --retry 3 -o /dev/null https://hc-ping.com/<your-uuid>
fi
```

Healthchecks ayrıca `/start` ve `/fail` ping varyantlarını destekler ve çıkış kodunu URL içinde kabul edebilir; böylece tek bir check takılan işleri de yakalar. Sonuç: ölü bir sunucu, devre dışı bir zamanlayıcı ve silinmiş bir crontab satırı aynı sonucu doğurur, yani çalan bir telefon. Genel yaklaşım ve diğer izleyiciler için [cron işi hata uyarıları](/tr/blog/cron-job-failure-alerts) yazısına bakın.

## Adım 4: Yedeğin güncel ve geri yüklenebilir olduğunu doğrulayın

Bir yedek zamanında çalışıp `0` ile çıkabilir ve yine de işe yaramaz olabilir; örneğin bir bağlama başarısız olduktan sonra boş bir dizini yedekliyorsanız. Ayrı bir günlük işe iki ucuz sağlık kontrolü ekleyin:

**Snapshot yaşı.** En yeni snapshot beklediğinizden eskiyse uyarın:

```bash
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
```

**Depo bütünlüğü.** `restic check` depo yapısını doğrular. Haftada bir çalıştırın; büyük depolarda `restic check --read-data-subset=5%` her şeyi okumadan veriden örnek alır. Sıfırdan farklı çıkışta uyarın.

Hiçbiri gerçek bir geri yükleme testinin yerini tutmaz. Üç ayda bir, doğrulayabileceğiniz bir dosyayı geçici bir dizine geri yükleyin. Yedeğin çalıştığını kanıtlayan tek test budur.

## Adım 5: Yalnızca önemli olduğunda çalsın

Her uyarı sizi arıyorsa kanalı sessize alırsınız ve o zaman gerçekten önemli olanda çalmaz. Tek kanalda seviyeleri ayırmak için Echobell [koşullarını](/tr/docs/conditions) kullanın:

```
status == "failed" || status == "stale" || status == "auth-failed"
```

`incomplete` ve `warning` durumlarını, **Zamana Duyarlı (Time Sensitive)** ya da normal ikinci bir kanala gönderin; böylece çalmadan kilit ekranınızda görünürler. Gündüz hatalarının sessiz kalmasını istiyorsanız, koşullar referansında anlatılan UTC değişkenleriyle bir zaman penceresi ekleyin.

## Sık sorulan sorular

### Yedekleme başarısız olduğunda nasıl bildirim alırım?

Yedekleme komutunu sarmalayın, çıkış kodunu okuyun ve sıfırdan farklı her kodda bir webhook gönderin. Hiç başlamayan çalışmalardan da haberdar olmak için Healthchecks.io gibi bir dead man's switch ekleyin.

### restic'in hangi çıkış kodlarında uyarı almalıyım?

Gerçek bir başarısızlık anlamına gelen `1`, `10`, `11` ve `12` için yüksek sesle uyarın. `3` kodunu (snapshot oluştu ama bazı dosyalar okunamadı) bir izin sorununu gizleyebileceği için incelenmesi gereken bir uyarı olarak ele alın.

### Bir yedeğin sessizce çalışmayı bıraktığını nasıl anlarım?

Bir heartbeat kullanın: iş başarıda izleyiciye ping atar, ping geciktiğinde izleyici uyarır. Hata kancası bunu yakalayamaz, çünkü hatayı üretecek bir şey çalışmıyordur.

### Başarılı bir çıkış kodu bir yedeğe güvenmek için yeterli mi?

Hayır. Bu, aracın bittiği anlamına gelir; verinin eksiksiz ya da geri yüklenebilir olduğu anlamına gelmez. Snapshot yaşını kontrol edin, düzenli bütünlük kontrolleri çalıştırın ve geri yüklemeyi düzenli olarak test edin.

### E-posta yerine telefon araması alabilir miyim?

Evet. E-postayı kaçırmak kolaydır. Echobell'deki bir arama kanalı gelen çağrı gibi davranır ve iOS Odak modunu aşar; böylece saat 03.00'teki başarısız bir yedek fark edilir.

## Özet

Üç dedektör üç hata modunu kapsar: başarısız olan çalışmalar için çıkış kodu sarmalayıcısı, başarılı ama işe yaramaz çalışmalar için güncellik kontrolü ve hiç gerçekleşmeyen çalışmalar için heartbeat. Bunları bir arama kanalına yönlendirin, uyarıları daha sessiz bir kanalda tutun; bozuk bir yedek, kaybedilmiş bir hafta sonu yerine beş dakikalık bir düzeltmeye dönüşsün.

[Echobell'i iPhone için indirin](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-backup-failure-alerts-tr&mt=8) ya da [Google Play'den edinin](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid), `backups` kanalını oluşturun ve çaldığını duymak için sarmalayıcıyı bir kez bilerek yanlış bir parolayla çalıştırın.

## İlgili yazılar

- [Cron işi hata uyarıları](/tr/blog/cron-job-failure-alerts)
- [Geliştiriciler için uyarı yorgunluğu rehberi](/tr/blog/fix-alert-fatigue-developer-guide)
- [Kanal koşulları referansı](/tr/docs/conditions)
- [Webhook entegrasyonu rehberi](/tr/docs/webhook)
- [SSL sertifikası süre sonu uyarıları](/tr/blog/ssl-certificate-expiry-alerts)